Re: scribus-generator now provides python2-tkinter in Fedora 30 ?

[Mátyás Selmeci]

On 11/5/19 4:36 AM, Felix Schwarz wrote:
> Am 05.11.19 um 10:05 schrieb Zbigniew Jędrzejewski-Szmek:
>> That seems to be a bug.
> 
> Ok, I filed https://bugzilla.redhat.com/show_bug.cgi?id=1768831
> (Hopefully we can get this fixed asap because we won't be able to fix this 
> automatically once python2-tkinter was removed in existing installs.)
> 
> Felix

If you need a workaround right now, I was able to reinstall
python2-tkinter by first installing the versionlock plugin
(python3-dnf-plugin-versionlock) and running

dnf versionlock exclude scribus-generator
dnf versionlock exclude scribus

which prevented the current, broken versions of scribus
from getting installed.

-Mat
___
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

Re: update hung in "pending" status

[Mátyás Selmeci]

On 7/31/19 10:17 PM, Kevin Fenzi wrote:
> On 7/31/19 4:18 PM, Mátyás Selmeci wrote:
>> Hi,
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-f0f74bf64a and 
>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb3b2a2164 have been 
>> stuck in "pending" status for several hours now.  Can someone kick them so 
>> they get into testing?
> 
> Updates pushes for stable releases happen once a day, starting at 00:00.
> 
> Those are both in the current pushes that are going out now... they
> should be out in a few more hours.
> 
> kevin

Ah, I didn't know that.  I've seen emails go by about stuck updates which is 
why I thought this might be the case.

If I want to get an early start on testing those packages, should I just 
download them from Koji?

Thanks,
-Mat
___
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

update hung in "pending" status

[Mátyás Selmeci]

Hi,

https://bodhi.fedoraproject.org/updates/FEDORA-2019-f0f74bf64a and 
https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb3b2a2164 have been stuck 
in "pending" status for several hours now.  Can someone kick them so they get 
into testing?

Thanks,
-Mat

-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
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

[EPEL-devel] Re: Update on EPEL-8 Status

[Mátyás Selmeci]

On 07/01/19 07:57, Stephen John Smoogen wrote:
> # Update on EPEL-8 Status
>
> ## Why is EPEL-8 Taking So Long (tl;dr:)
>
> 1. Getting koji to work smoothly with modules has been hard. A multi-level 
> fix has had to be worked to get it working in staging.
>   * Needed a way to split out default modules to deal with koji merge 
> options. [Grobisplitter](https://github.com/puiterwijk/grobisplitter) was 
> written to do this
>   * [Koji](https://pagure.io/koji) needed further patching to deal with 
> src.rpms with same NVR but different targets (some python2 and python3 come 
> from same src.rpm but were built in different times).
>   * DNF reposync from RHEL-7 would delete the wrong files if you tried the 
> ``--newest`` (fixed.)
>   * DNF does not know how to reposync modules if it is not the local arch. 
> Code Ready Builder is not always in sync with packages in main trees. If you 
> need a -devel and it isn’t in CRB, then you have to wait until it is there to 
> build something.
> 2. As a couple of fixes landed in mergerepo and koji, we are re-evaluating 
> how we do builds in the next stage of building.
>
>
> ## Introduction
>
> In May of 2019, Red Hat released their 8.0 release of Red Hat Enterprise 
> Linux (RHEL). Usually, the Extra Packages for Enterprise Linux (EPEL) group 
> would have a beta available at that time or sooner. With RHEL-8, it has taken 
> a lot longer to get things rolling.
>
> ## Repository Changes
>
> EPEL packages are built inside of the Fedora Projects' build infrastructure. 
> This is done by downloading the packages from Red Hat's public Content 
> Delivery Network (CDN), and then having the Fedora artifact build system 
> (koji) use the release as an external build channel. Koji looks at packages 
> in a different way than other build commands like 'mock' do. Where mock is 
> meant to just build packages, koji is designed about auditing the entire 
> lifecycle of a package. In other words, if you want to know how a package in 
> Fedora 12 was built and all its children interacted over time in the 
> buildroots.. you can do that with enough work and the koji databases. With 
> mock you have a couple of log files which tell you what was pulled into a 
> buildroot but how those were built would require you finding their log files, 
> etc etc. A developer can also download those packages and look at them to see 
> what was in them and how they were built.
>
> The strength of koji is that you can have a credible chain of builds to know 
> where things came from. However this doesn't work too well with building 
> packages for EPEL where koji doesn't know where the RHEL kernel came from. 
> Koji uses mergerepo to look at the external packages provided, determines the 
> src.rpm they would come from and determines what the latest version it would 
> use from each. From this it creates a 'buildroot' which it will use to build 
> packages from. This has worked pretty well for building packages from 
> RHEL-5,6, and 7. The major downside has been where someone built a package 
> with the same src.rpm name which koji then decides is the master no matter if 
> a newer version shows up in RHEL.
>
> This all changed with modularity. Koji really only has a rudimentary idea of 
> rpms and repositories.. it has zero idea about modules and the rules it has 
> used to determine what an external package is are thrown out with modules.
>
> 1. Packages with different names may come with from the same src.rpm. In 
> RHEL-8 many python27 and python36 packages have the same parent src.rpm but 
> were in different build times. Koji's standard repo comparison mode will 
> choose one or the other.
> 2. Packages may have the same names-version-releases but were built in 
> different module streams (say perl-5.26 and perl-5.24) Koji would then choose 
> a package depending on whatever had the largest src.rpm which meant it could 
> try to build a buildroot with  perl-5.24 perl modules but perl-5.26  as the 
> master perl.
>
> If a developer uses mock to build a package with default repositories, mock 
> calls dnf which knows about modules and does the right thing. In the case 
> where you want it to do the 'wrong' thing you can also over-ride mock to do 
> that. With koji, further tools are needed to make this work. If you are 
> building a new module, then the Modular Build System (MBS) sits on top of 
> koji and tells koji what to do. It will look at the module yaml file and turn 
> on/off various modules so that it can build in what is needed. To build 
> non-modular packages, other fixes are needed. One of these is called 
> Ursa-Major which was a set of scripts to pull in needed data from a third 
> database and pull things in as needed. However, this was not adopted in 
> Fedora for general use so the EPEL group looked for something different.
>
> The temporary solution written by Patrick Uiterwijk is called grobisplitter 
> (https://github.com/puiterwijk/grobisplitter) which relies on the fact 

Re: Fedora 31 System-Wide Change proposal: Python means Python3

[Mátyás Selmeci]

On 06/28/19 10:46, mcatanz...@gnome.org wrote:
> 
> On Fri, Jun 28, 2019 at 10:42 AM, mcatanz...@gnome.org wrote:
>> If Fedora has /usr/bin/python, then at least we have a *chance* to make the 
>> scripts we care about work in both python2 and python3 (our current plan). 
>> Whereas without /usr/bin/python, we're really out of options. So I very much 
>> support /usr/bin/python -> /usr/bin/python3. It will cause some problems for 
>> us and we'll have a difficult transition period, but at least there will 
>> exist the possibility of transitioning.
> 
> Accidentally hit send too soon. I meant to add: /usr/bin/python -> 
> /usr/bin/python3 is better than all available alternatives. It's the only way 
> that /usr/bin/python remains in Fedora pointing to a supported python 
> interpreter. And that is the only chance that cross-platform python scripts 
> have to work without pain and suffering (beyond that of making the script 
> work with both python2 and python3). We're not python developers and just 
> want to run some python scripts; wrapping up all our python inside e.g. bash 
> scripts that start a virtualenv would be a sad end to this tale.

Thank you.  I work on multiple platforms so I make my utility scripts
work on both Python 2 and 3 and only use the standard library.  It
would be super annoying if I had to have multiple versions just because
of the shebang line.

-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
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

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

[Mátyás Selmeci]

On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
> 
> let's drop the requirement and ordering on systemd (as implemented by
> %systemd_requires) from packages which provide systemd units.
> 
> I now filed [1], which removes the recommendation to use %systemd_requires.
> Quoting from that ticket:
> 
>Nowadays systemd.rpm does a preset-all call when it is installed.
>This means that individual packages which provide systemd units and
>call %systemd_post in their %post will work fine no matter if they
>are installed *before* or *after* systemd.

Is this true for the version of systemd in RHEL 7 and compatible as well?
How will this affect EPEL packages?
-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
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

[EPEL-devel] Re: missing libcomps

[Mátyás Selmeci]

On 3/14/19 5:59 PM, Kevin Fenzi wrote:
> On 3/14/19 3:22 PM, Mátyás Selmeci wrote:
>> Hi,
>>
>> libcomps
>> (https://koji.fedoraproject.org/koji/packageinfo?packageID=16769)
>> seems to have been untagged from epel 7?  We can't install koji
>> anymore because python-libcomps is a dependency.
> 
> It should be in rhel-extras...
> 
> ah, it's' called python2-libcomps there. So, perhaps we need to rebuild
> koji for the different name? Can you file a bug on koji to that effect?
> 
> kevin

Bug sent: https://bugzilla.redhat.com/show_bug.cgi?id=1689291


Should we assume in general that the rhel-extras or centos-extras or
equivalent repos need to be enabled if we want to use EPEL?

Thanks,
-Mat
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

[EPEL-devel] missing libcomps

[Mátyás Selmeci]

Hi,

libcomps
(https://koji.fedoraproject.org/koji/packageinfo?packageID=16769)
seems to have been untagged from epel 7?  We can't install koji
anymore because python-libcomps is a dependency.

-Mat
-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: Retire YUM 3

[Mátyás Selmeci]

On 2/4/19 11:27 AM, Stephen John Smoogen wrote:
> On Mon, 4 Feb 2019 at 12:14, Mátyás Selmeci  wrote:
>>
>> On 1/31/19 1:05 PM, Kevin Fenzi wrote:
>>> On 1/30/19 1:39 PM, Adam Williamson wrote:
>>>
>>>> Question: how plausibly can we sort of "test retire" yum? i.e. just
>>>> somehow run a single compose process without it included, and see what
>>>> breaks?
>>>
>>> Well, we could block yum in koji and remove it from all builders and see
>>> what happens, but I think it will break all epel builds (unless we
>>> switch epel to use dnf for buildroot population too) at least.
>>>
>>> kevin
>>
>> Can we put DNF in EPEL so people still targeting EL 7 can adapt their
>> scripts?
>>
> 
> Dnf was added to RHEL-7 in the latest release as a tech preview and is
> in CentOS extras. As such later versions can not be put in EPEL
> without major packaging work.
>

Sounds good, I'll check it out from there.

>> As a side note, this is a problem with Python 3, too; I can't get any
>> Python 3 bindings for the yum/rpm libs on EL 7, which makes it hard to
>> port software that uses them.
>>
> 
> There will be work on making a newer Python36 in EPEL in the next
> couple of months.
> 

I didn't know new packages would be added as part of that, I thought
it was a rebuild / update of existing packages.  Thanks, that would be
useful.

-Mat
___
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

Re: F30 Self-Contained Change proposal: Retire YUM 3

[Mátyás Selmeci]

On 1/31/19 1:05 PM, Kevin Fenzi wrote:
> On 1/30/19 1:39 PM, Adam Williamson wrote:
> 
>> Question: how plausibly can we sort of "test retire" yum? i.e. just
>> somehow run a single compose process without it included, and see what
>> breaks?
> 
> Well, we could block yum in koji and remove it from all builders and see
> what happens, but I think it will break all epel builds (unless we
> switch epel to use dnf for buildroot population too) at least.
> 
> kevin

Can we put DNF in EPEL so people still targeting EL 7 can adapt their
scripts?

As a side note, this is a problem with Python 3, too; I can't get any
Python 3 bindings for the yum/rpm libs on EL 7, which makes it hard to
port software that uses them.

-Mat

-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
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

Re: F30 Self-Contained Change proposal: Retire YUM 3

[Mátyás Selmeci]

On 2/1/19 10:23 AM, Neal Gompa wrote:
> On Fri, Feb 1, 2019 at 10:23 AM Sérgio Basto  wrote:
>>
>> koji-builder, mash and repoview are ready to work without yum ?
>>
> 
> There's a pending PR for fixing koji-builder:
> https://pagure.io/koji/pull-request/1117
> 
> Mash is dead and not used in infra anymore, so it doesn't matter.
>

What's the replacement?


-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
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

Re: Fedora Lifecycles: imagine longer-term possibilities

[Mátyás Selmeci]

On 11/16/18 5:17 PM, Jason L Tibbitts III wrote:
>> "MM" == Matthew Miller  writes:
> 
> MM> It's the fundamental contradiction that all operating systems face:
> MM> users complain "too fast and too slow!" at the same time.
> 
> Well, then lengthening the Fedora lifecycle does not seem to me to be
> the real solution.  Instead, I think, it's to piggyback onto the already
> long RHEL lifecycle but provide isolated pieces of "instability"
> (i.e. new stuff) to people who want them.
> 
> Or more simply, don't try to slow Fedora down.  Let Fedora be Fedora and
> instead leverage Fedora to speed RHEL up in selected areas where people
> want it.
> 
> MM> As noted elsewhere in this thread, many packagers are already doing
> MM> this: maintaining a slow stream for EPEL or for RHEL as part of
> MM> their day job, and a fast stream in Fedora.
> 
> So let RHEL be the core bits, moving as fast or as slow as Red Hat wants
> to support.  And let someone who wants "the new stuff" layer things over
> that.  Fedora could provide the layers, which move as fast as Fedora
> does.
> 
> Of course, the practicalities of that and the potential combinatorial
> explosion of options and interdependencies might render the whole idea
> pointless.  But that's supposed to be what the whole module system
> solves.  Or is it the flatpak system?  Maybe both.  And I believe those
> are both conveniently supported by RHEL8.
So basically something EPEL-like that doesn't have the "don't mess
with the base OS" restriction?  That would be really nice.  The long
time between RHEL releases (which seems to be getting worse, too)
makes supporting it a real pain for my group.

-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
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

Re: Attention Gmail users, please turn off HTML mail

[Mátyás Selmeci]

On 10/17/18 2:38 PM, Anderson, Charles R wrote:
> On Wed, Oct 17, 2018 at 02:12:37PM -0500, Bruno Wolff III wrote:
>> On Wed, Oct 17, 2018 at 14:48:52 -0400,
>>   "tonynel...@georgeanelson.com"  wrote:
 ... For html only messages you would either need to reject them or rewrite 
 them, both of which have issues.
>>> I've used elinks to do that in an email forum I wrote. It worked better 
>>> than doing it with, say, Beautiful Soup.
>>
>> That is a big risk on your list serve processor. I would want to use 
>> something 
>> a lot safer than elinks (or lynx) to parse unsolicited email messages. What 
>> I 
>> do at work is use a simple perl script, but it doesn't do a great job.
> 
> I use a perl script with these modules and some regexps to clean up
> the result:
> 
> use HTML::Strip; use HTML::LinkExtor; use HTML::Entities
> qw/decode_entities/; use URI::Escape qw/uri_unescape/;
> ___

Is this Perl script available somewhere?  I'm interested in having
something better than elinks for the times I read HTML mail in Mutt.

Thanks,
-Mat

-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
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

[EPEL-devel] updating condor

[Mátyás Selmeci]

Hi folks,

The versions of condor in EPEL 6 (8.4.3) and 7 (8.3.8) are out of date 
and no longer supported by upstream. The current release is 8.6.10.


Most configurations should work fine without changes between the two 
versions. However, there are some admin-visible changes, most notably 
enabling use of cgroups by default, and listening on a single port 
instead of a port range. There are also some changes to the default 
output of the command-line tools.


Are these changes considered too disruptive for EPEL stable?

Thanks,
-Mat

--
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences

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

Re: [Guidelines change] Changes to the packaging guidelines

[Mátyás Selmeci]

On 04/23/2018 01:06 PM, Jason L Tibbitts III wrote:

The Python guidelines now more clearly indicate that use of %{__python},
%{python_sitelib} and %{python_sitearch} is forbidden.

  * https://fedoraproject.org/wiki/Packaging:Python#Macros
  * https://pagure.io/packaging-committee/issue/745



The EPEL guidelines for Python [1] still recommend these for EPEL6 
instead of %{python2_sitelib}, etc.  Is that still the case, or should 
those guidelines be updated?


Thanks,
-Mat

[1] https://fedoraproject.org/wiki/EPEL:Packaging#Python
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Mátyás Selmeci]

On 03/15/2018 10:14 AM, Patrick Uiterwijk wrote:

Hi all,

If you maintain any application in Fedora Infra (or outside) that
tries to parse things out of RPM names, you might be interested in
this.

For those wondering where I've been spending most of my time the last
few weeks: I've been deep in the internals of Bodhi fixing all kinds
of issues I've found between it and Modularity (turns out enabling
composing was just the beginning).

At some point, I was informed that for modules, they are throwing all
kinds of old assumptions out of the door.
One of those is the good old Name-Version-Release in RPM land.

Modules do not have an NVR, they have an NSVC: Name, Stream, Version, Context.
Name is the name of the module ("nodejs").
Stream is a stream, like "6", "7" or "8", these are crucial for the
parallel availability that modules are trying to accomplish.
Version is a date/time stamp, used to indicate new versions in the
same name-stream.
Context is a hash of some information in the built module that makes
it so that the nodejs-6-20170314 built for Fedora 28 has a different
identifier than the one built for Fedora 29.

There are some additional fields for installed things (arch and
profile), but those aren't really important for things trying to
parse/show module names I think.

One of the interesting things they wanted to also allow: dashes in streams.
As a consequence, when you get an N-S-V.C as modules are represented
in Koji builds, doing a .rsplit('-', 2) will not give you Name,
Stream, Version.Context per se.
You could totally have a module called
nodejs-my-stream-5-20170314.abcd, with name=nodejs,
stream=my-stream-5, version=20170314, context=abcd.
There is no way for you to independently figure out what the NSVC
components are, you will need to ask Koji, and use its name, version
and release fields (with name=name, version=stream,
release=version(.context)).

Also as a consequence, modules should not be dash-separated in
anything the users see.
For user consumption, they are Name:Stream:Version:Context, so you may
need to manually convert between one representation and the other if
you need to look up in koji or other systems versus display to users.

Also, note that if you are touching older modules in Koji (e.g.
because you go through all koji builds), modules before February 19th
will be lacking the Context field.
However, I've been told that those modules will not be used, so unless
you or your app goes spelunking in koji (for fun and profit), you
should never see those.

I hope that this is useful information for anyone else finding
themselves having to parse NVRs/NSVs.

Regards,
Patrick


This does not affect traditional RPM/SRPM packages, right?

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

Re: Proposed Fedora packaging guideline: More Go packaging

[Mátyás Selmeci]

On 12/17/2017 01:11 AM, nicolas.mail...@laposte.net wrote:

Hi,

I am proposing for inclusion a set of rpm technical files aimed at automating 
the packaging of forge-hosted projects.

- Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging
- https://pagure.io/packaging-committee/issue/734
- go-srpm-macros RFE with the technical files: 
https://bugzilla.redhat.com/show_bug.cgi?id=1526721


Hi,

This looks pretty cool! One thing I notice in the limitations section of 
your draft is a lot of "we can't do XXX due to lack of release 
discipline..."


Do you have any recommendations for Go programmers on how to structure 
their software so that it is easy to package?


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

Self Introduction: Matyas (Mat) Selmeci

[Mátyás Selmeci]

Hi all,

My name is Matyas Selmeci and I work for the Open Science Grid, a 
collaboration of ~100 universities and research labs around the US that 
share batch computing resources with each other. We've been developing 
an RPM-based software stack for our users, some of which are based on 
EPEL packages, and would like to contribute our changes and any packages 
that we think are of general use into EPEL. I look forward to being part 
of the community and working with all of you!


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

[EPEL-devel] missing orphaned packages reports?

[Mátyás Selmeci]

Hi,

I haven't seen new 'orphaned packages' emails since July. Is that on 
purpose?


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

common location of spec files in upstream sources

[Mátyás Selmeci]

Hi,

For upstream projects that provide spec files in their repositories, do 
y'all tend to see a common location for the spec files? Like 
dist/.spec or rpm/.spec, etc. My organization is trying to 
standardize on a location for the software we maintain, and it would be 
better to use something that many in the open source community also use.


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

Re: Updates for Firefox 57 beta

[Mátyás Selmeci]

On 10/18/17 07:21, James Hogarth wrote:



On 17 Oct 2017 17:40, "Gerald B. Cox" > wrote:




On Tue, Oct 17, 2017 at 1:33 AM, James Hogarth
> wrote:


And even if we hypothetically forked Firefox (as that is what
it would be) to add legacy extension capability back it would
mark a significant divergence with upstream and I'm not sure
if addons.mozilla.org  could even
be used then anyway as it'd detect FF57 and state that older
extensions are not supported. That doesn't even go into the
legal situation as to whether we could even call it Firefox
with such divergence (remember Iceweasel?) ... there's a
reason there's a whitelist on the Firefox packages for build
permissions after all.

And how long would you want FF packagers to maintain such a
patchset for? Even the next ESR will drop legacy extensions.



Yup!  It's a non-starter. Mozilla knows exactly what they are
doing - and have made their decision.


https://blog.mozilla.org/addons/2017/04/05/compatibility-firefox-54/#comment-223852






To keep interested parties here in the loop...

The COPR is operational and a draft for review has been entered into 
the magazine with details for this preview on the magazine mailing list.


I'll keep the COPR updated as best I can with any changes to the the 
Fedora 27 package... may lag by a day or so but I'll do my best ;)


Note that although there are F25 builds in the COPR there will be no 
Firefox 57 builds going into the official F25 repos so that one really 
is no support and just there to ease testing.


I'll keep the COPR running and updated until the Firefox 57 packages 
eventually return to the F26 testing repo after it is released upstream.


The COPR will be removed at that point.


Where is the COPR? I searched for "firefox" on copr.fedorainfracloud.org 
but did not find it.


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

Re: Why is Fx 57 in Updates Testing?

[Mátyás Selmeci]

On 10/11/17 08:32, Martin Stransky wrote:

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and I was under the impression that
BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.

Yes, I understand there is an annotation NOT to push Fx 57 to stable 
- but

I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to 
test software planned for Fedora thus I don't see any problem here.


There are many extensions which aren't yet available for Fx 57 - and 
we're

effectively moving up the timetable by putting it in updates testing.


Do you think it's better when it suddenly appears on stable at 
2017-11-14? I do not.


ma.


Will an older version (either 56 or the ESR version, 52) also be 
included in Fedora 27 as a separate package?


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

[EPEL-devel] Re: RHEL-7.4 is released (build roots updating)

[Mátyás Selmeci]

Is there a list of the packages that will be removed from EPEL because 
they are in RHEL 7.4? (And when that will happen?) Many of our users are 
on Scientific Linux and SL 7.4 is not out yet.


Thanks,
-Mat

On 08/01/17 16:24, Stephen John Smoogen wrote:



RHEL-7.4 was released today and so the build roots for EPEL packages 
will be updated as soon as the automatic reposync is done.


This may cause problems for EPEL builds for CentOS people so please be 
careful in pushing items from epel-testing to epel until CentOS is 
caught up.


--
Stephen J Smoogen.



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

[EPEL-devel] Re: broken python2-multilib dependancy in latest koji package push for EL6

[Mátyás Selmeci]

On 08/10/16 12:15, Kevin Fenzi wrote:

On Wed, 10 Aug 2016 12:57:10 -0400
"B. Karhan"  wrote:


.the update koji-1.10.1-8.el6 has a require of python2-multilib which
is only added to python-multilib-1.1-5.el6 (and later), so the
parallel push of python-multilib-1.1-4.el6 does not satisfy the
dependancy. the highest version of koji without the dependancy is
koji-1.10.1-6.el6.


Check updates-testing?

according to:
https://bugzilla.redhat.com/show_bug.cgi?id=1340704
this is already fixed in those updates.

kevin


Hi,

Is there an ETA for when the new python-multilib will get out of testing?

Thanks,
-Mat

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: [EPEL-devel] python-six missing in epel6?

[Mátyás Selmeci]

Was this a recent change? I see it in CentOS 6.7 but not CentOS 6.6, and 
it looks like Scientific Linux hasn't caught up either...

-Mat
On 08/12/15 15:29, Stephen John Smoogen wrote:

On 12 August 2015 at 13:30, Mátyás Selmeci mat...@cs.wisc.edu wrote:

Hi,
I can no longer find the package python-six in EPEL 6. This is a
requirement for installing mock. I didn't see it in the orphaned list - what
happened?
Thanks,
-Mat



python-six is not in EPEL but in the base packages (either CentOS or RHEL).



___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel









smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[EPEL-devel] python-six missing in epel6?

[Mátyás Selmeci]

Hi,
I can no longer find the package python-six in EPEL 6. This is a 
requirement for installing mock. I didn't see it in the orphaned list - 
what happened?

Thanks,
-Mat




smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] EPEL meeting minutes 2015-01-09

[Mátyás Selmeci]

On 01/09/15 12:04, Stephen John Smoogen wrote:

http://meetbot.fedoraproject.org/epel/2015-01-09/epel.2015-01-09-17.00.log.html
17:03:30  smooge  OK we don't have much old business from the last meeting 
because it was a couple of weeks ago
17:03:45  smooge  We had the orphaning and tyll found some bugs in his script 
that didn't show all the orphans
17:03:52  smooge  so we have another batch.
17:04:23* bstinson  hasn't had a chance to look through the email yet, how bad 
is it looking?
17:04:36  smooge  nirik, bstinson do we want to have another orphan day or 
just have tyll do them when he has a chance?
17:04:48  smooge  bstinson, it isn't any better than it was before the last 
one :)
17:04:54* Jeff_S  here a bit late
17:05:16  nirik  did we say 6 weeks or something? or has the timeout already 
expired.
17:05:33  smooge  nirik, most of these packages are over 6 weeks (some are 22)
17:05:48  nirik  perhaps one last warn email and do them next week?
17:05:57  bstinson  +1
17:06:06  smooge  ok will send out an email and ask tyll to do them next week 
around Thursday?

Hi,
Are the orphan purges going to be batched in the future, or will they be 
automatic once a package hits that 6-week mark? What kind of advance 
warning can users expect before these packages (and their dependents) 
get removed?

-Mat



smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] EPEL meeting minutes 2015-01-09

[Mátyás Selmeci]

On 01/09/15 15:44, Stephen John Smoogen wrote:



On 9 January 2015 at 13:04, Mátyás Selmeci mat...@cs.wisc.edu 
mailto:mat...@cs.wisc.edu wrote:


On 01/09/15 12:04, Stephen John Smoogen wrote:


http://meetbot.fedoraproject.org/epel/2015-01-09/epel.2015-01-09-17.00.log.html
17:03:30  smooge  OK we don't have much old business from the last 
meeting because it was a couple of weeks ago
17:03:45  smooge  We had the orphaning and tyll found some bugs in his 
script that didn't show all the orphans
17:03:52  smooge  so we have another batch.
17:04:23* bstinson  hasn't had a chance to look through the email yet, how 
bad is it looking?
17:04:36  smooge  nirik, bstinson do we want to have another orphan day 
or just have tyll do them when he has a chance?
17:04:48  smooge  bstinson, it isn't any better than it was before the 
last one :)
17:04:54* Jeff_S  here a bit late
17:05:16  nirik  did we say 6 weeks or something? or has the timeout 
already expired.
17:05:33  smooge  nirik, most of these packages are over 6 weeks (some 
are 22)
17:05:48  nirik  perhaps one last warn email and do them next week?
17:05:57  bstinson  +1
17:06:06  smooge  ok will send out an email and ask tyll to do them next 
week around Thursday?

Hi,
Are the orphan purges going to be batched in the future, or will
they be automatic once a package hits that 6-week mark? What kind
of advance warning can users expect before these packages (and
their dependents) get removed?
-Mat


As far as I understand it is not possible to automate this. Thus it 
will always be sort of batched. There is a weekly email which covers 
what packages are currently orphaned. People should watch for those if 
they are interested.


Does that answer the question? [Sorry headache so words not working well.]

--
Stephen J Smoogen.
Yes, thank you. Will you continue to give advance notification of the 
purge dates?

-Mat



smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Out of virtual memory on ARM builder

[Mátyás Selmeci]

On 02/14/2014 02:53 PM, Dmitry Butskoy wrote:

Dennis Gilmore wrote:

The arm builders all have 4gb of ram. how much ram should the tests
need?


BTW, some big application -- seamonkey (former mozilla/netscape 
suite) -- fails to build on arm due to the same reason -- not enough 
memory on the build host.



~buc

This may be a stupid question, but can you solve this by putting more 
swap on those builders?

-Mat




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

EPEL broken mirror: rhn.brown.edu

[Mátyás Selmeci]

Hi,

Sorry if I'm reporting this to the wrong list, but the rhn.brown.edu 
mirrors for EPEL are broken (the domain doesn't even resolve). It's not 
listed in the public mirrors list at 
https://mirrors.fedoraproject.org/publiclist but is part of the 
mirrorlist that yum uses at 
https://mirrors.fedoraproject.org/mirrorlist?repo=epel-5arch=x86_64 .


Thanks,
-Mat
--
-Matyas Selmeci
Open Science Grid Software Team
Center for High Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences



smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: using rpms for non-root installs

[Mátyás Selmeci]

  
  
Michael Stahnke wrote:

ls zip-3.0-1.el6.x86_64.rpm
  mkdir $HOME/.myrpm
  cp -pr /var/lib/rpm/* $HOME/.myrpm/
  chown -R $USER  $HOME/.myrpm/
  rpm -Uvh --justdb --dbpath $HOME/.myrpm zip-3.0-1.el6.x86_64.rpm
  rpm2cpio  zip-3.0-1.el6.x86_64.rpm | cpio  -idmv
  rpm -q --dbpath $HOME/.myrpm zip


This is very useful. I'll play around with it to see how much
tooling we'd have to write around it.

Jan Zelený wrote:

  How about using Software Collections? It doesn't solve the installataion by 
unprivileged user but it solves installation into non-standard location:

http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/index.html

You are right, because of the unprivileged user requirement I can't
use it directly, but it seems like there's a lot I can learn from
how you folks did this.


Also thanks Adam and Kevin for the background knowledge, and in
general thank you all for your help!

-Mat

-- 
  -Matyas Selmeci
  Open Science Grid Software Team
  Center for High Throughput Computing
  University of Wisconsin-Madison 
  




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

using rpms for non-root installs

[Mátyás Selmeci]

  
  
Hi,

This may be a long shot, but I am interested in repackaging some
RPMs (for example, some of the Globus packages in EPEL, as well as
grid software that my group builds) such that the software in them
may be installed by unprivileged users, or into a non-standard
location such as an NFS share. I'd like to use existing RPMs,
preferably binaries, as a starting point to avoid duplicating work.
(Naturally a lot of post-install scripting would be needed to fix
binaries such that they'd work with the path they were installed
into).

Have there been any projects with this goal in mind?
Have any of you had experience with this sort of thing and have
tips, tools, etc. that might help me out in this?

Thanks in advance,
-Mat
-- 
  -Matyas Selmeci
  Open Science Grid Software Team
  Center for High Throughput Computing
  University of Wisconsin-Madison 
  




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: OpenMPI, Emacs and libotf problems

[Mátyás Selmeci]

Adam Williamson wrote on Wed, Jul 06, 2011 at 12:54:48PM -0700:
 On Wed, 2011-07-06 at 22:46 +0300, Jussi Lehtola wrote:
  On Wed, 06 Jul 2011 12:39:14 -0700
  Adam Williamson awill...@redhat.com wrote:
   On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote:
So, this library is missing. However, this should have been
installed as its a dependency, right?

It can be seen that there are two providers listed for libotf.so.0.
Since 'openmpi' was already installed, so it didn't bother
installing 'libotf'. I could simulate the scenario on a Fedora 15
installation:
   
   The problem is that openmpi includes a libotf.so.0, but it's not in a
   path that the system will usually look in for shared libraries, it's
   in (libdir)/openmpi/lib/ . openmpi probably shouldn't have a private
   copy of libotf in the first place (assuming that's what it is, and
   not just a naming coincidence), but if it's going to have one, it
   should have a line in the spec to prevent RPM auto-provides from
   giving the openmpi package a Provides for libotf.so.0.
  
  It's certainly not the same libotf, since OpenMPI does not have
  *anything* to do with truetype fonts.
  
  Even though the library is installed in a non-system directory,
  applications that link against libotf will get an automatically
  generated Requires: against it anyways.
 
 Well, packages get an auto-generated Requires: for libotf.so.0. Anything
 that claims to provide libotf.so.0 will satisfy this. The most correct
 solution is simply for openmpi to stop claiming to provide libotf.so.0
 because, for practical purposes, it does not provide it: even if the
 library in question were the same one, openmpi's copy is not in a
 location that other packages will know how to use, so in practical
 terms, it does not provide the library.

If I run into this kind of a situation (a false auto-generated
Provides), is it possible to disable just that one entry, or do I have
to disable AutoProv entirely and keep track of the libs myself?

Thanks,
-matyas

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel