Re: Guidance for a python package update

2023-05-30 Thread Troy Curtis Jr 
On Tue, May 30, 2023, 3:13 AM Miro Hrončok  wrote:

> Hi Troy.
>
> On 29. 05. 23 18:01, Troy Curtis Jr wrote:
> > I'm currently working on the update for python-Levenshtein [1] and I
> have a
> > question about the best way to proceed.
> >
> > In the intervening time since the last release we have packaged, a new
> > maintainer has taken over maintenance, and built the updates around a
> stack of
> > other packages (rapidfuzz-cpp, python-rapidfuzz, scikit-build, etc). Now
> that
> > all these dependencies are available I can look to actually do the
> update. As
> > part of the updates, the current maintainer has deprecated the original
> pypi
> > name of "python-Levenshtein" in favor of the more typical name without
> the
> > "python-" prefix. He is continuing to maintain the "python-Levenshtein"
> pypi
> > package for compatibility, but now it is just an empty package which
> defines
> > "Levenshtein" as a dependency [2]. This means the upstream for the
> Fedora
> > python-Levenshtein package must point to the new Levenshtein package in
> order
> > to get the actual package contents. However, this means the metadata for
> the
> > package indicates the name "Levenshtein" which translate to a provide
> for
> > "python3.11dist(levenshtein)", but that is different than the currently
> > provided "python3.11dist(python-levenshtein)", which current
> dependencies
> > require. One option would be to simply manually add a
> > "python3.11dist(python-levenshtein)" provide, but it seems this seems
> > specifically prohibited in the Python packaging guidelines [3].
>
> And there is a reason. If the package "claimed" to be
> python3dist(python-levenshtein), yet the Python metadata would say it's
> levenshtein, all automation that generates requirements for
> python3dist(python-levenshtein) would happily accept it, but fail on
> Python
> level. For example, the %pyproject_buildrequires macro, when it encounters
> an
> unmet dependency on levenshtein on the Python level, prints out
> python3dist(levenshtein) and restarts for dnf to take over. dnf then
> installs
> the package but the macro still does not see the package on Python level,
> so it
> prints it out again and restarts...
>
> > I think there are 2 options:
> > - Manually provide the legacy name outside of the python package
> meta-data
>
> Please don't.
>
> > - Rebuild all users of the provide to use the new name
>
> It's not that many:
>
> $ repoquery -q --repo=rawhide{,-source} --whatrequires
> 'python3.11dist(python-levenshtein)' --whatrequires
> 'python3dist(python-levenshtein)'
> paperwork-0:2.1.2-2.fc38.src
> python-paperwork-backend-0:2.1.2-2.fc38.src
> python3-paperwork-0:2.1.2-2.fc38.noarch
> python3-paperwork-backend-0:2.1.2-2.fc38.noarch
>
> > The main downside to the second approach is that nothing would provide
> the
> > python-Levenshtein name, which is still present and usable via pypi and
> > perfectly compatible with the current library implementation.
>
> But do we need it in Fedora?
>
> If you really need this, you could insert a second dist-info metadata to
> the
> package, so it would ship:
>
> %{python_sitearch}/...actual content here...
> %{python_sitearch}/Levenshtein-0.21.0.dist-info/
> %{python_sitelib}/python_Levenshtein-0.21.0.dist-info/
>
> That way, it provides both names on Python and RPM level both.
>
> But I consider that an overkill.
>

I presume that the name change would be considered a breaking change, since
any applications using the system libraries expecting that name would not
install properly (outside of Fedora packages which could be updated
together with the change). This in spite of the fact that the actual API is
fully compatible. That is the one case that seems like it might be worth
while to add this second distinfo.


> > So what is the appropriate course of action here?
>
> Please, attempt to change the dependents.
>

Since the requires generally come from the package metadata itself, does
this mean changing upstream for each dependency? Or just patch for our
Fedora packages? Presumably they could be patched and then built together
with the updated name, I presume this is where side tags come in to play?
(It'll be a new experience for me!)



> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Guidance for a python package update

2023-05-29 Thread Troy Curtis Jr 
I'm currently working on the update for python-Levenshtein [1] and I have a
question about the best way to proceed.

In the intervening time since the last release we have packaged, a new
maintainer has taken over maintenance, and built the updates around a stack
of other packages (rapidfuzz-cpp, python-rapidfuzz, scikit-build, etc). Now
that all these dependencies are available I can look to actually do the
update. As part of the updates, the current maintainer has deprecated the
original pypi name of "python-Levenshtein" in favor of the more typical
name without the "python-" prefix. He is continuing to maintain the
"python-Levenshtein" pypi package for compatibility, but now it is just an
empty package which defines "Levenshtein" as a dependency [2]. This means
the upstream for the Fedora python-Levenshtein package must point to the
new Levenshtein package in order to get the actual package contents.
However, this means the metadata for the package indicates the name
"Levenshtein" which translate to a provide for
"python3.11dist(levenshtein)", but that is different than the currently
provided "python3.11dist(python-levenshtein)", which current dependencies
require. One option would be to simply manually add a
"python3.11dist(python-levenshtein)" provide, but it seems this seems
specifically prohibited in the Python packaging guidelines [3].

I think there are 2 options:
- Manually provide the legacy name outside of the python package meta-data
- Rebuild all users of the provide to use the new name

The main downside to the second approach is that nothing would provide the
python-Levenshtein name, which is still present and usable via pypi and
perfectly compatible with the current library implementation.

So what is the appropriate course of action here?

Thanks for the help,
Troy

1: https://bugzilla.redhat.com/show_bug.cgi?id=1036607
2: https://github.com/maxbachmann/python-Levenshtein/blob/main/setup.cfg
3:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine-readable-provides
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Package owner required for ImageMagick

2021-10-13 Thread Troy Curtis Jr 
On Tue, Oct 12, 2021, 10:14 PM Luya Tshimbalanga 
wrote:

>
> On 2021-10-12 15:37, Michael Cronenworth wrote:
> > Hi all,
> >
> > I would like to put out a public call for a new primary owner for
> > ImageMagick[1].
> >
> > I only picked it up a few years ago to prevent it from being orphaned,
> > but I no longer have the desire or time to maintain it.
> >
> > Thanks,
> > Michael
> >
> > [1] https://src.fedoraproject.org/rpms/ImageMagick
> >
> Hello Michael,
>
> I will take that package because it is used by Fedora Design team for
> conversion and some applications depend on it.
>

Luya, if you'd also like some help, I'd be happy to co-maintain this with
you. I find myself using it in various scenarios.

Troy


> --
> Luya Tshimbalanga
> Fedora Design Team
> Fedora Design Suite maintainer
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package downgrades from F34 -> F35 (categorized list included)

2021-09-20 Thread Troy Curtis Jr 
On Mon, Sep 20, 2021 at 8:44 AM Fabio Valentini 
wrote:

> ...

- ulauncher-0:5.13.0-1.fc34 > ulauncher-0:5.12.1-1.fc35
> ...


I just submitted the new ulauncher 5.14 update
https://bodhi.fedoraproject.org/updates/FEDORA-2021-894c62b141 (and
similarly for F34) so it should be resolved shortly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: orphaning rarian

2021-08-22 Thread Troy Curtis Jr 
On Sun, Aug 22, 2021 at 10:16 AM Iago Rubio  wrote:

> On Sun, 2021-08-22 at 09:00 -0400, Troy Curtis Jr wrote:
> >
> > On Wed, Aug 11, 2021 at 6:25 PM Mukundan Ragavan <
> > nonamed...@gmail.com> wrote:
> > > I am orphaning rarian (https://src.fedoraproject.org/rpms/rarian).
> >
> >
> > It seems the impact is a little more than that:
>
> Just to point it out, this have been discussed at the list with mixed
> opinions.
>

Thanks for pointing out the existing discussion. I promise I searched for a
discussion first, but I guess since it was embedded in the "New maintainer
experience"
thread, I skipped right over it .


>
> I was aiming at getting the rarian package myself as a first package on
> Fedora as stated here
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V24Y6IYST4EUWRUAVHGLUOAU3XF46WD2/
>
> I have made a package on Copr that builds on rawhide.
> https://copr.fedorainfracloud.org/coprs/iago/rarian/
>
> The spec can be checked here
> https://github.com/iagorubio/rarian-rpm
>
> Some people said it was good to revive it
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DU2LHKUN4OR6FPKIDAB5ASS3BUINUXZK/
>
> There is also the opinion that is better to let rarian go at this point
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7HFCYWGIO3KYUAKGH7IYY4UG76VWFZ3Y/
>
> If Mukundan want to take it over again, and there is a consensus about
> maintaning the package, he can use my spec as a starting point, if he
> don't want to take it again I may submit a review request and try to
> get an sponsor, or let other packager take it over once the review is
> done.
>

I can certainly understand needing to let something go at some point, but
looking at the list two packages catch my eye: dia and viking. I tend to
always fall back to dia for diagramming and I just recently installed
viking for use (though it isn't something I use daily or even weekly).

While it seems that dia went dormant for a while, it looks like there is
some new activity in the repo [1], though no new releases yet. It is
possible that dia dropped rarian/scrollkeeper in the lastest master branch,
but for sure the current release, 0.97.3, requires it. Perhaps the dia
maintainer huzaifas will have better insight into the current state of
this? (cc'ed)

viking looks to be seeing current attention upstream, and there is even a
newer release [2] than what is currently available in Fedora Linux (created
[3]). The current Fedora package definitely fails to generate manpages
without rairian-compat, but it does seem that 1.9 has dropped this
requirement. Maybe fab has more context on this? (cc'ed)

A quick look at etherape shows active upstream that appears to have dropped
scrollkeeper as well, and the Fedora package is a few versions behind.
Without directly checking all the other packages, I suspect that Kalev is
right: projects with active upstreams have migrated away from it. I think
for now I'll take the package, and pull in the changes that you made in
your copr to make sure it continues to build. Once you are sponsored (sorry
I'm not able to do so), you are welcome to co-maintain. However, my
intention with taking the package is simply as a stop-gap until dependent
packages make releases that make their way into Fedora. For me personally,
that's mostly dia. Once all the active upstreams have in fact moved off of
it, then I think it would make sense to retire it for real.


>
> If the decision to let it go, goes ahead, it may live on Copr as is for
> the time being in case someone needs it.
>
>
>
Troy

1: https://gitlab.gnome.org/GNOME/dia/-/commits/master
2: https://github.com/viking-gps/viking/releases/tag/viking-1.9
3: https://bugzilla.redhat.com/show_bug.cgi?id=1996469
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: orphaning rarian

2021-08-22 Thread Troy Curtis Jr 
On Wed, Aug 11, 2021 at 6:25 PM Mukundan Ragavan 
wrote:

>
> I am orphaning rarian (https://src.fedoraproject.org/rpms/rarian). As
> far as I can tell, nothing in Fedora depends on it anymore.
>
> # dnf repoquery --releasever rawhide --whatrequires librarian\*
> Last metadata expiration check: 0:02:50 ago on Wed 11 Aug 2021 06:03:30
> PM EDT.
> rarian-compat-0:0.8.1-27.fc34.x86_64
> rarian-devel-0:0.8.1-27.fc34.i686
> rarian-devel-0:0.8.1-27.fc34.x86_64
>

It seems the impact is a little more than that:

# dnf repoquery --releasever rawhide --whatrequires rarian-compat
Last metadata expiration check: 0:00:07 ago on Sun 22 Aug 2021 08:51:18 AM
EDT.
alleyoop-0:0.9.8-18.fc35.x86_64
etherape-0:0.9.18-8.fc35.x86_64
gnome-translate-0:0.99-39.fc35.x86_64
grhino-0:0.16.1-13.fc35.x86_64
mail-notification-0:5.4-100.git.9ae8768.fc35.x86_64
pioneers-0:15.6-3.fc35.x86_64
ucview-0:0.33-21.fc35.i686
ucview-0:0.33-21.fc35.x86_64

There also appears to be some mention in BuildRequires in a few packages:

# dnf repoquery '--disablerepo=*' '--enablerepo=*-source' --arch=src
--releasever rawhide --whatrequires rarian-compat
bless-0:0.6.3-3.fc35.src
dia-1:0.97.3-18.fc35.src
gnome-search-tool-0:3.6.0-20.fc35.src
ignuit-0:2.24.3-10.fc35.src
mdbtools-0:0.9.3-2.fc35.src
moserial-0:3.0.16-2.fc35.src
stardict-0:3.0.6-17.fc35.src
viking-0:1.8-7.fc36.src
xiphos-0:4.2.1-11.fc35.src

Props to the Packager Dashboard[1]. I stumbled across this there while
checking to see if there were any orphaned packages I cared about.


>
> Mukundan.
> --
> GPG Key: E5C8BC67
>
>
1:  https://packager-dashboard.fedoraproject.org/user/orphan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

2021-02-16 Thread Troy Curtis Jr 
On Mon, Feb 15, 2021 at 10:02 PM Dominique Martinet 
wrote:

> Michael Catanzaro wrote on Mon, Feb 15, 2021 at 08:46:57PM -0600:
> > We removed the fallbacks due to complaints from users who didn't want DNS
> > ever going to Cloudflare or Google. So the lack of fallback is expected
> and
> > should not be reported as a bug.
>
> setting DNS= (or DNS="") explicitely should not fallback, I agree with
> that. There are people who want no DNS whatsoever and that should be
> configurable.
>
> But if extract_first_word() returned a non-empty string and
> manager_add_dns_server_by_string fails (for all iterations of the loop),
> it should definitely kick some fallback in -- the user obviously wanted
> *something*, it just doesn't work.
>
>
Steve's situation provides the perfect example for why a fallback is likely
undesirable. It sounds like his
configuration never worked. There were explicit DNS values configured that
weren't being used, yet
he never noticed because it fell back to something that seemed to work. It
would take a deeper and
deliberate look before the user realized the desired configuration wasn't
applied. It is better to error
than guess in many cases.


>
> > I think we have larger issues with DNS server assignment on cloud
> servers,
> > which I've reported as https://pagure.io/fedora-server/issue/10. But I
> also
> > notice Steve's case is different, since he really does have some static
> DNS
> > configuration, just using commas where spaces are required. So seems
> like a
> > misconfiguration by the cloud provider?
>
> Not sure where the configuration snippet with comma comes from but yes
> ultimately it's "just" a configuration error.
> Nevertheless, a config that somehow worked until a recent update through
> fallback, I don't think we want more unhappy users :)
>
> --
> Dominique
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Why are we shipping debug builds of pythons?

2018-08-04 Thread Troy Curtis Jr 
On Sat, Aug 4, 2018 at 5:16 PM Miro Hrončok  wrote:

> Hi,
>
> an interesting discussion came up in the Python Maint team recently,
> about not shipping python3-debug and python2-debug.
>
> On the Chesterton's fence principle [0], I'd would like to know why are
> we building and shipping them before we have a discussion about their
> removal to save build time and remove packaging cruft.
>
> Anyone has an idea? Those packages are meant to debug Python, yet all
> people I know who do that, build they own Python for that purpose (often
> from the master branch).
>

The other main use for the Python debug package is debugging Python C
extensions.  I recently made very good use of it while using GDB to debug
some extensions I was working on.  This is more than just having debug
symbols, which of course is essential, but the debug build means that when
you are stepping through the code, you can more easily follow what the
interpreter is doing.  Also, I think that is the package that has some
niceties that extend GDB to work even better with Python code.


> I tracked down the introduction of the python-debug package in this
> commit [1] by David Malcolm (CCed) @ 8 years ago, added in Fedora 14
> shortly before upgrade to 2.7. Yet the commit message lacks rationale.
>
> [0] https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
> [1]
>
> https://src.fedoraproject.org/rpms/python/c/f020abd35954981b383884105dad425ba9c6637a
>
> Thanks,
> --
> Miro Hrončok
> --
> Phone: +420777974800 <+420%20777%20974%20800>
> IRC: mhroncok
>

Troy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AHOMI7GX6IBXSINVDDTBX6GYZF2Y5QLY/

Re: Parselmouth Badge

2017-11-06 Thread Troy Curtis Jr 
On Mon, Nov 6, 2017, 5:02 AM Petr Viktorin <pvikt...@redhat.com> wrote:

> On 11/05/2017 08:39 PM, Troy Curtis Jr wrote:
> > So, do upstream contributions count toward Parselmouth badges? ;)
>
> I'm afraid the way they're set up now, they're just for the Fedora
> packages – mainly because I don't really want to get in the business of
> reviewing how each upstream contribution affected Fedora.
>
> Should that be changed?
>

I don't necessarily think that, I was just wondering. I could see how doing
so would be a much bigger scope. Plus there isn't a shortage of opportunity
in just packages!

Troy
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: [HEADS-UP] unannounced libfastjson ABI change breaks rsyslog

2017-11-01 Thread Troy Curtis Jr 
On Wed, Nov 1, 2017 at 5:49 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> Dear Fedora,
>
>
..snip..


> This breaks, for example, rsyslog-8.30.0-3, which was compiled against
> libfastjson-0.99.7, but didn't go out together with it, so when I ran
> dnf update, the set contained only new rsyslog, which, when run with
> libfastjson-0.99.6 (same SONAME!) simply dies:
> # rsyslogd -n
> rsyslogd: symbol lookup error: rsyslogd: undefined symbol:
> fjson_global_do_case_sensitive_comparison
>
> Dear maintainers, please use abipkgdiff when doing library updates.
> Upstreams do break ABI without bumping SONAME sometimes.
>
>
I'm not sure if it is a real issue or not.  A user in #fedora got bit by
this where his rsyslog was upgraded but not his libfastjson.  Updating to
libfastjson-0.99.7 allowed rsyslog to startup and begin logging.  But it
appeared to die quickly.  This happened at least twice.

There could be other things going on with his setup, but I thought I'd
point out a potential issue to be on the lookout for even if the missing
symbol has been resolved.

Troy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Extension Build Question/Recommendation

2017-10-21 Thread Troy Curtis Jr 
I'd like to know what everyone's take on the best way to build python
extensions for both python2 and python3 when the upstream build system can
only build for one at time.

The path I took for the gpsd update I submitted was to use two independent
source trees, then build one for python2 and another for python3.  But of
course if the software is much more than just the python extensions, it is
rebuilding a lot of the same code, with the same result.  This could be
considered a bit wasteful of CPU and disk space, and certainly increases
build time.

The only other option I could come up with would be to build for python2,
install that, and then within the install section, reconfigure with python3
and rebuild (which should hopefully only rebuild the python related parts),
and finally install again with the python3 configured setup.  One pitfall I
see with this method is the potential need to manually clean out certain
python2 based generated files if the reconfigure isn't enough.  Plus this
results in building in the install section, which seems a little bit off.

IMHO the first option is better.  Sure, it wastes some CPU cycles and disk
space, as well as increases package build time.  However, it seems less
prone to needing manual tweaks, provides a much cleaner distinction between
the two build configs, and would make it easier to enable/disable the two
variants as desired.

But that is just my opinion, I'm curious what the Python SIG consensus is.

Troy
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

portingdb

2017-10-05 Thread Troy Curtis Jr 
What is the story with the python3 portingdb instance (
http://fedora.portingdb.xyz/)?  It's been down for quite a while now.

Troy
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Python 3 porting Bugzilla guidance

2017-09-27 Thread Troy Curtis Jr 
On Mon, Sep 18, 2017 at 7:01 AM Petr Viktorin  wrote:

> It's only automatic for Bugzilla. If upstream is not using the Fedora/RH
> bugzilla (which it shouldn't, really), a URL for the upstream discussion
> needs to be added manually. And of course you can open a portingdb
> ticket for that.
>
>
> Nowadays I don't want portingdb to have too much info about upstream,
> because:
> - Upstream discussions for a projects are usually not hard to find.
> - Bugzilla is Fedora-specific, so people from other OSs won't look there.
> - portingdb is mainly used by the Fedora Python SIG; both upstreams and
> other Fedorans aren't likely to look there.
>
> So I prefer portingdb having just an URL for the upstream discussion –
> and even that isn't needed if interested people can easily find that
> discussion.
>
>
So if there are pending issues, patches, or merge requests upstream related
to the python3 porting effort there should be a portingdb ticket created
requesting a link to the upstream discussion/status be added? And I should
*not* create a bugzilla ticket blocking
https://bugzilla.redhat.com/show_bug.cgi?id=1322027 like I did with
https://bugzilla.redhat.com/show_bug.cgi?id=1492382 ?  Or perhaps both
should/could be done as perhaps they are used by separate teams tracking
different status?  Just trying to get a handle on the preferred route.

Thanks,
Troy


>
> Once there's a py3-compatible release upstream, it's enough to open a
> bugzilla for the Fedora package and link it to the tracking bug (see
> [Python 3 Bug Filing]). Then portingdb will eventually update.
>
>
> [Python 3 Bug Filing]:
> https://fedoraproject.org/wiki/User:Pviktori/Python_3_Bug_Filing
>
> --
> Petr Viktorin
>
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Package submission question

2017-09-04 Thread Troy Curtis Jr 
On Mon, Sep 4, 2017 at 3:54 AM Petr Viktorin <pvikt...@redhat.com> wrote:

> On 09/04/2017 06:21 AM, Troy Curtis Jr wrote:
> > I have a version of the gpsd package which I believe addresses this
> > ticket https://bugzilla.redhat.com/show_bug.cgi?id=1390812.  I've been
> > looking around about the right way to submit.  I thought it would be by
> > using a pull request from within the pagure instance at
> > src.fedoraproject.org <http://src.fedoraproject.org>.  However, I cannot
> > authenticate with my ssh key.  There is no where to add it within
> > pagure, and my FAS key doesn't seem to be sufficient.  So perhaps this
> > isn't they way?  Then I was reading through
> >
> http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request
> > , but it seems a bit geared toward brand new packages, so I was not sure
> > if that was in fact the proper coarse.
> >
> > I'd appreciate any pointers as to the proper direction to get this
> > updated package updated.  In the meantime, I'll fix the rpmlint warnings
> > I just found!
>
> That shouldn't be happening.
> What's your FAS username?
>
troycurtisjr


>
> If you can push the changes to another public Git repository (e.g.
> GitHub), that could be a workaround while we get Pagure access sorted out.
>

Ok so Pagure is the right way to go then.  I tried importing my key again,
but I'm still getting denied.  I can use the same key on a different linux
host as well as with gitlab.com, so I'm fairly confident my local
configuration is correct.  I assume this is unrelated, but I also can't
seem to tie my FAS account correctly to the

For the time being then, I've pushed my changes to
https://gitlab.com/troycurtisjr/fedora-pkg-gpsd.git under the
'python2-packaging' branch for review. Additionally, I used copr to build
for several releases, which you can find at
https://copr.fedorainfracloud.org/coprs/troycurtisjr/gpsd/build/597872/

--
Troy Curtis


>
> --
> Petr Viktorin
>
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Package submission question

2017-09-03 Thread Troy Curtis Jr 
I have a version of the gpsd package which I believe addresses this ticket
https://bugzilla.redhat.com/show_bug.cgi?id=1390812.  I've been looking
around about the right way to submit.  I thought it would be by using a
pull request from within the pagure instance at src.fedoraproject.org.
However, I cannot authenticate with my ssh key.  There is no where to add
it within pagure, and my FAS key doesn't seem to be sufficient.  So perhaps
this isn't they way?  Then I was reading through
http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request
, but it seems a bit geared toward brand new packages, so I was not sure if
that was in fact the proper coarse.

I'd appreciate any pointers as to the proper direction to get this updated
package updated.  In the meantime, I'll fix the rpmlint warnings I just
found!

Thanks,
Troy
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Question about working with upstream vs patches

2017-09-02 Thread Troy Curtis Jr 
On Sat, Sep 2, 2017 at 7:40 AM Miro Hrončok <mhron...@redhat.com> wrote:

> On 2.9.2017 05:53, Troy Curtis Jr wrote:
> > Howdy,
>
> Hi Troy,
>
> > I'd like to help work toward the Fedora move toward Python 3.  There is
> > lots of good information out there about much of the process, but I did
> > have a few questions about how you like to do things, and the proper
> > work-flow.
>
> This is always a great thing to hear. Welcome. Hopefully we will be able
> to help you with your questions.
>
> > If I start working on a particular package, should I mention as such in
> > the associated porting bugtracker ticket?  I could see it either way,
> > either it needless clutters the ticket comments, or it is helpful for
> > the next guy to pick a different package.
>
> It's always helpful to say: "Hi, I'm going to work on this." It
> eliminates the possibility that some work is being done by multiple
> persons at the same time.
>
> Also, it allows others to say things like: "Hey Troy, are you still
> working on this? What's your status?"
>
> Don't worry about needless cluttering. Any information relevant to the
> ticket is good. Even if it says: "I'm still interested in this, but I
> haven't been able to progresses trough XYZ, as it seems I'm stuck at ABC."
>
>
Sounds great, I'll put a comment on the ticket.


> > I already started looking at gpsd, since I've had some experience with
> > it, and it is bound to be challenging!  I was proven right pretty
> > quickly.  It is all perfectly workable, but I wanted to know the general
> > expectation.  For changes to python modules/scripts themselves to
> > support python 3, does this need to flow through upstream in all cases?
>
> In 99.98% cases, it has to go trough upstream. I can see a situation,
> where patches are being reviewed upstream, likely to be accepted, but we
> need this in Fedora ASAP, so patches are applied in Fedora before
> accepted upstream. But that should only happen if this package is
> blocking other important packages. I think we did this with
> python-yubikey (not quite sure).
>
> Applying Python 3 compatibility patches downstream only (i.e. only in
> Fedora, not yet proposed to upstream) is strongly discouraged. I would
> only see a fit there if there is already a python3-xyz package and in an
> update, it loses Python 3 compatibility by accident, users start filling
> bugs and everything is broken. In that case, I would see a situation
> where patching downstream first and proposing to upstream immediately
> after is a good way.
>
> But if the python3-xyz package is not yet in Fedora, always go upstream
> first.
>
> Doing Python 3 compatibility patches downstream only you are basically
> maintaining a fork. If you want to do that (sometimes you do, because
> upstream is dead or doesn't want Python 3), there are better places to
> maintain forks than Fedora spec + patches. This happened with
> python-ldap vs. python-pyldap (fork is maintained on GitHub).
>
>
Makes perfect sense, I am just used to seeing the pile of patches in RPMs.
I'll
certainly start working with upstream on it.


>
> > Most of my packaging experience has been with the enterprise distros,
> > and there are always loads of patches carried along with the sources,
> > but in this case do you require an official release from the upstream
> > project with the necessary changes?
>
> Official release is the best. If the release will come late and the
> package is blocking something, taking patches form upstream version
> control system (e.g. git) and applying them to get Python 3 support
> might be applicable. (It happened in the past.) This always depends on
> the reason.
>
> Consider those situations:
>
>   * Next release of xyz will be in 3 weeks and will bring Python 3 support.
>
>   * Next release of abc might happen in a year, if there are no serious
> problems. Python 3 support is in  git master and will be only officially
> released in the next release. There are 5 packages that require abc and
> are Python 3 ready, only waiting for abc.
>
> Those are obviously different. Always apply common sense.
>
> > I certainly plan on providing all the changes upstream, but the last
> > release was almost 2 years ago, so I'm not certain when a new one might
> > be expected (the project is still active though).
>
> Get the patches to upstream. If accepted, talk to them about releasing.
> If they are reluctance to do a release soon, revisit this question.
>
>
> Hope my answers were helpful. Find me or others on #fedora-python IRC
> channel if you need real time clarifications. (Or continue
> asynchronously

Question about working with upstream vs patches

2017-09-01 Thread Troy Curtis Jr 
Howdy,

I'd like to help work toward the Fedora move toward Python 3.  There is
lots of good information out there about much of the process, but I did
have a few questions about how you like to do things, and the proper
work-flow.

If I start working on a particular package, should I mention as such in the
associated porting bugtracker ticket?  I could see it either way, either it
needless clutters the ticket comments, or it is helpful for the next guy to
pick a different package.

I already started looking at gpsd, since I've had some experience with it,
and it is bound to be challenging!  I was proven right pretty quickly.  It
is all perfectly workable, but I wanted to know the general expectation.
For changes to python modules/scripts themselves to support python 3, does
this need to flow through upstream in all cases?  Most of my packaging
experience has been with the enterprise distros, and there are always loads
of patches carried along with the sources, but in this case do you require
an official release from the upstream project with the necessary changes?

I certainly plan on providing all the changes upstream, but the last
release was almost 2 years ago, so I'm not certain when a new one might be
expected (the project is still active though).

Thanks,
Troy Curtis
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org