[389-devel] Re: Groups are not accessible by filter
> On 29 Apr 2019, at 15:00, Anuj Borah wrote:
>
> @William Brown
>
> Sorry my bad , syntax was wrong .
>
> (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
> ['attrlist=cn:sn:uid:testUserAccountControl'])"))
> 6
>
> Thanks .
>
>
> On Mon, Apr 29, 2019 at 10:26 AM Anuj Borah wrote:
> @William Brown
>
> This is the filter :
> "testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl']
>
> len(topo.standalone.search_s(DEFAULT_SUFFIX,
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> > 6
>
> But the full filter does not fit with filter module .
>
> > (Pdb) len(Accounts(topo.standalone,
> > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> > ['attrlist=cn:sn:uid:testUserAccountControl']))
> > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > (Pdb) len(Accounts(topo.standalone,
> > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> > ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
> > 'No such file or directory'}
>
>
> Regards
> Anuj Borah
>
That filter string seems really … uhh, interesting. You are testing:
(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
['attrlist=cn:sn:uid:testUserAccountControl’])
Is that really a valid filter?
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: dropping autogenerated dependency on pkg-config
On Sun, Apr 28, 2019 at 11:04 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > Hi everyone, > > currently, we autogenerate a dependency on pkg-config for all rpms > that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" > returns 4632 entries on my laptop. > > This has always felt backward to me: those packages *provide* something > that is used by pkg-config, they don't *require* pkg-config for anything. > As an analogy, packages with headers are read by a C compiler, but > we don't make them require gcc, and if a package ships an .so file, we > don't add a dependency on the linker to it. Instead, anything which wants > to consume .pc files should simply depend on the tools that consume those > files (pkg-config, pkgconf, or a custom re-implementation). > > Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config > (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh). > > Note: autogenerated Provides/Requires like pkgconfig(foo) are not > part of this proposal. > > Advantages: > - less entries in the dependency graph > - removal of illogical dependency > - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, > libpkgconf) > (Those packages are small, maybe 200k together so this isn't a strong >reason.) > > Disadvantages: > - stuff that uses pkg-config or pkgconf will need to grow a dependency > (e.g. meson which invokes /usr/bin/pkg-config internally). > so there will be some churn. > It would be nice to have something like Requires: (pkg-config if pkgconfig(*)) which would install pkgconf if any packages providing pkgconfig(…) are installed.. But I'm afraid we can't do that now. Zbyszek > ___ > 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 > ___ 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: dropping autogenerated dependency on pkg-config
On Sun, Apr 28, 2019 at 11:34 PM Neal Gompa wrote: > On Sun, Apr 28, 2019 at 4:57 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > Hi everyone, > > > > currently, we autogenerate a dependency on pkg-config for all rpms > > that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" > > returns 4632 entries on my laptop. > > > > This has always felt backward to me: those packages *provide* something > > that is used by pkg-config, they don't *require* pkg-config for anything. > > As an analogy, packages with headers are read by a C compiler, but > > we don't make them require gcc, and if a package ships an .so file, we > > don't add a dependency on the linker to it. Instead, anything which wants > > to consume .pc files should simply depend on the tools that consume those > > files (pkg-config, pkgconf, or a custom re-implementation). > > > > Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config > > (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh). > > > > Note: autogenerated Provides/Requires like pkgconfig(foo) are not > > part of this proposal. > > > > Advantages: > > - less entries in the dependency graph > > - removal of illogical dependency > > - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, > libpkgconf) > > (Those packages are small, maybe 200k together so this isn't a strong > >reason.) > > > > Disadvantages: > > - stuff that uses pkg-config or pkgconf will need to grow a dependency > > (e.g. meson which invokes /usr/bin/pkg-config internally). > > so there will be some churn. > > > > I've worked in distributions that have implemented this policy, and > it's often much more frustrating to work with because of it. It's not > always obvious that pkgconfig missing is the reason why stuff doesn't > build or otherwise work correctly. > > I'm pretty sure the reason for having the auto-generated requirement > on pkg-config was to make it easy and obvious to use stuff through > pkgconfig. > > I'm personally not in favor of doing this. I know that recently there > has been this kick to shrink the default buildroot and minimize the > dependency chain in extreme ways. I'm fairly certain a chunk of this > has to do with RHEL modularity, but there's also the obvious bit of > speeding up buildroot construction. > I hope you are not talking about my Change Proposal because it has nothing to do with Modularity and/or RHEL :) But to be honest, this isn't a significant drain on the dep chain (if > we still had the other pkgconfig implementation, it might be, since > that pulled in glib2 in the minimal tree). > > If the problem is pkgconf-m4, I could be persuaded to drop > pkgconf-pkg-config's requirement on it. I kept it there principally > because the old pkgconfig package had the m4 file in there too. > I think I would start first dropping make from buildroot. > The impact is minimal, it's a developer-side dependency anyway, and > it's often useful to have. So from my point of view, I don't see a > problem with it. And the dependency generator already makes it > "/usr/bin/pkg-config", so you could theoretically swap it with any > other conforming implementation. > > In the end, I don't see any reasonable benefit for doing this, and it > just makes developer and packaging work more frustrating. > > Also, w.r.t. so files, we _do_ pull in the linker library. The library > "ld-linux-$ARCH.so.$SOMAJOR" is always pulled in by every rpm > containing a library. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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 > ___ 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: Module's package branch name to be aligned?
Modularity team, On below definition of the modularity document, there is a problem, as Vit said. https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/#_package_branch_name The problem is If we use X.Y.Z as a package branch name with rpms/bar, for example the situation is like this. modules/foo 2.5 rpms/foo 2.5 rpms/bar 2.5 In this case, seeing rpms/bar 2.5 branch, people tend to recognize it, "bar"'s 2.5 branch. But it's wrong. It can be actually bar 1.2.3 that is included in module foo 2.5. rpms/bar's situation means "rpms/ package branch" in the list. You see several patterns in it. Maybe I covered most modules situation. https://pagure.io/jaruga-modules-branches postgresql module solves the situation like this. modules/foo 11 rpms/foo stream-postgresql-11 rpms/bar stream-postgresql-11 reviewboard module solves the situation like this. modules/foo 3.0 rpms/foo 3.0 rpms/bar 1.2 (it means bar 1.2 version's branch) I wish at least recommended way is documented in the modularity section of the page. -- Jun ___ 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
[389-devel] Re: Groups are not accessible by filter
@William Brown
Sorry my bad , syntax was wrong .
(Pdb) len(Accounts(topo.standalone,
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
['attrlist=cn:sn:uid:testUserAccountControl'])"))
6
Thanks .
On Mon, Apr 29, 2019 at 10:26 AM Anuj Borah wrote:
> @William Brown
>
> This is the filter :
> "testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl']
>
> len(topo.standalone.search_s(DEFAULT_SUFFIX,
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> > 6
>
> But the full filter does not fit with filter module .
>
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
> 'No such file or directory'}
>
>
> Regards
> Anuj Borah
>
>
>
>
>
>
> On Mon, Apr 29, 2019 at 10:17 AM William Brown wrote:
>
>>
>>
>> > On 29 Apr 2019, at 12:33, Anuj Borah wrote:
>> >
>> > @William Brown
>> >
>> > Thanks for the tip!
>> >
>> > (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX,
>> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
>> ['attrlist=cn:sn:uid:testUserAccountControl']))
>> > 6
>> > (Pdb) len(Accounts(topo.standalone,
>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
>> > 6
>> >
>> > We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with
>> filter , like we do with search_s .
>> >
>> > (Pdb) len(Accounts(topo.standalone,
>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
>> ['attrlist=cn:sn:uid:testUserAccountControl']))
>> > *** TypeError: filter() takes 2 positional arguments but 3 were given
>> > (Pdb) len(Accounts(topo.standalone,
>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
>> ['attrlist=cn:sn:uid:testUserAccountControl']"))
>> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2,
>> 'info': 'No such file or directory'}
>> >
>> > Again i have to use "re" module for the same .
>> >
>> >
>>
>> What are you trying to achieve?
>>
>>
>> Sincerely,
>>
>> William Brown
>>
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>>
>>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[389-devel] Re: Groups are not accessible by filter
@William Brown
This is the filter :
"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
['attrlist=cn:sn:uid:testUserAccountControl']
len(topo.standalone.search_s(DEFAULT_SUFFIX,
ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> 6
But the full filter does not fit with filter module .
> (Pdb) len(Accounts(topo.standalone,
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
['attrlist=cn:sn:uid:testUserAccountControl']))
> *** TypeError: filter() takes 2 positional arguments but 3 were given
> (Pdb) len(Accounts(topo.standalone,
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
['attrlist=cn:sn:uid:testUserAccountControl']"))
> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
'No such file or directory'}
Regards
Anuj Borah
On Mon, Apr 29, 2019 at 10:17 AM William Brown wrote:
>
>
> > On 29 Apr 2019, at 12:33, Anuj Borah wrote:
> >
> > @William Brown
> >
> > Thanks for the tip!
> >
> > (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX,
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> > 6
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
> > 6
> >
> > We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with
> filter , like we do with search_s .
> >
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
> 'No such file or directory'}
> >
> > Again i have to use "re" module for the same .
> >
> >
>
> What are you trying to achieve?
>
>
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
>
>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[389-devel] Re: Groups are not accessible by filter
> On 29 Apr 2019, at 12:33, Anuj Borah wrote:
>
> @William Brown
>
> Thanks for the tip!
>
> (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX,
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> 6
> (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
> 6
>
> We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with filter
> , like we do with search_s .
>
> (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> *** TypeError: filter() takes 2 positional arguments but 3 were given
> (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> ['attrlist=cn:sn:uid:testUserAccountControl']"))
> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 'No
> such file or directory'}
>
> Again i have to use "re" module for the same .
>
>
What are you trying to achieve?
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[Bug 1703790] perl-YAML-1.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703790 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-YAML-1.28-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb2c321d46 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2019-04-29 - 91% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/04/29/report-389-ds-base-1.4.1.2-20190428git6a6b8d9.fc29.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[389-devel] Re: Groups are not accessible by filter
> On 29 Apr 2019, at 12:15, Anuj Borah wrote: > > @William Brown > > Thank you for the clarification. Same thing was writing in the second mail of > this mail chain . I was missing the use case UniqueGroup(…).filter(). > > What about bellow filters . Can we use filter here also . > > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (| > (nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['cn', 'cn', 'cn']) > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (| > (nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['*', 'cn’] If you are filtering again accounts that are in a roll, then you would do: Accounts().filter(conditions) ... > ) > > And This one . > > topo.standalone.search_s(DEFAULT_SUFFIX, > ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.804:=16777216",['attrlist=cn:sn:uid:testUserAccountControl’] > ) > I think you need to think about this problem as “I want to run this filter and I expect to get these specific types back”. You aren’t simply doing a search, you are telling lib389 “find all accounts that match these conditions”. So if you do the nsRoleDN search against accounts, you’ll get all accounts in that nsroledn. If you do the nsroledn search agains groups, you’ll get all groups that are in that nsroledn. Perhaps you need to think of it that way, that you are expressing not just the conditions you want to find, but what types of things you expect them to be. If you can answer that question, youll have the answer to “how” to use filter for those searches. — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[389-devel] Re: Groups are not accessible by filter
@William Brown Thank you for the clarification. Same thing was writing in the second mail of this mail chain . I was missing the use case UniqueGroup(…).filter(). What about bellow filters . Can we use filter here also . topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (| (nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['cn', 'cn', 'cn']) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (| (nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['*', 'cn']) And This one . topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.804:=16777216",['attrlist=cn:sn:uid:testUserAccountControl']) Regards Anuj Borah On Mon, Apr 29, 2019 at 7:38 AM William Brown wrote: > > > > On 29 Apr 2019, at 11:53, Anuj Borah wrote: > > > > @William Brown > > > > The space did not make any difference . Look at bellow result . > > > > (Pdb) i > > '(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)' > > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(i) > > ^ Because you are using the wrong class. > > Filter will wrap your call because you are filtering over the set of > Accounts, not “generic searching”. If you want to search a group > OfUniqueNames, you need: > > UniqueGroup(…).filter(). > > Have a look at _mapped_object.py in def filter and youll see it does: > > def filter(self, search): > # This will yield and & filter for objectClass with as many terms > as needed. > search_filter = _gen_and([self._get_objectclass_filter(),search]) > > IE, your search of “uniqueMember=…” is then inserted such that: > > (&(objectClass=groupOfUniqueNames)(uniqueMember=…)) > > Because you are using Accounts, this is doing: > > (&(|(objectClass=nsAccount)(objectClass=person)…) (uniqueMember=…)) > > Which of course won’t find anything in a group, because Accounts are not > Groups. > > > So in fact, lib389 is doing exactly the right thing here, by saying “no, > your search is not safe or sane, so you don’t get any results”. Lib389 is > designed to prevent you making mistakes, and so will error or do nothing in > the cases where something is wrong, rather than allow a corruption or odd > behaviour to occur. > > > > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > > ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[389-devel] Second opinion on backend filter testing
Hi there,
Would really like a second opinion here (especially looking at you Ludwig since
you know this code well) about the behaviour of the filter test code.
I have been following up on the filter optimisation patch to understand why in
some conditions it causes IPA to fail.
Examining the logs that Mark provided me (thank you!!!), I have checked a
number of cases that looked like they could be suspect. Most of these were
conditions where searches yielded nentries=0, but some conditions were true.
An example of a query like this was also raised on the RH bugzilla. Here it is
exploded to make it easier to see:
ORIGINAL:
(&
(&
(|
(usercertificate;binary=)
(ipaCertMapData=X509:O=EXAMPLE.TEST,CN=Certificate
AuthorityO=EXAMPLE.TEST,CN=ipauser1)
(altsecurityidentities=X509:O=EXAMPLE.TEST,CN=Certificate
AuthorityO=EXAMPLE.TEST,CN=ipauser1)
)
(objectClass=posixAccount)
(uid=*)
(&
(uidNumber=*)
(!
(uidNumber=0)
)
)
)
(objectClass=ipaIDObject)
)
OPTIMISED:
(|
(objectclass=referral)
(&
(|
(usercertificate;binary=)
(ipaCertMapData=X509:O=EXAMPLE.TEST,CN=Certificate
AuthorityO=EXAMPLE.TEST,CN=ipauser1)
(altsecurityidentities=X509:O=EXAMPLE.TEST,CN=Certificate
AuthorityO=EXAMPLE.TEST,CN=ipauser1)
)
(objectClass=posixAccount)
(uid=*)
(uidNumber=*)
(!
(uidNumber=0)
)
(objectClass=ipaIDObject)
)
)
To me, observing this, these are identical - it appears the re-arrangement has
worked to fold the nested & conditions, and the re-arrangement has not altered
or lost components of the filter.
As a result, I think that it is not the filter optimisation itself that is
suspect, but the fact that the filter optimiser will cause the filter execution
code to operate in a different order of operations. An important aspect of the
optimisation is the we assume the filter test *must* be executed such that the
remaining conditions of the filter are upheld.
Observing the code I am wondering if there may be a logic error in the
application of the filter test bypass flags.
Note that in this case all line numbers are from branch:
https://pagure.io/389-ds-base/pull-request/50252
All searches take place in ldbm_search.c, starting in ldbm_back_search on line
306. The actual candidate set is built on line 625 via build_candidate_list.
On line ldbm_search.c:876 the filter bypass is evaluated by:
if (li->li_filter_bypass && NULL != candidates && !virtual_list_view &&
!lookup_returned_allids) {
}
li_filter_bypass comes from ldbm_config.c:1614, and appears to default to 1
after inspection of dse.ldif (nsslapd-search-bypass-filter-test: on).
candidates should be != NULL, and !vlv would be upheld. This means the
condition now is on not-lookup_returned_allids.
In build_candidate_list, lookup_returned_allids for a subtree search is set in
subtree_candidates ldbm_search.c:1140. This is determined by checking that
candidates is not NULL, and that candidates is equivalent to ALLIDS. Note that
if the candidate set is partially evaluated here this would cause
allids_before_scopingp (lookup_returned_allids) to be false.
So at this point, all conditions on ldbm_search.c:876 should be met. Imagine
we have a partial candidate set, below the filter test threshold. This would
cause idl_intersection or idl_union etc to execute: slapi_be_set_flag(be,
SLAPI_BE_FLAG_DONT_BYPASS_FILTERTEST); to indicate the partial nature of the
candidate set.
However I believe the issue may come from can_skip_filter_test in
ldbm_search.c:1289. In this function the flag
SLAPI_BE_FLAG_DONT_BYPASS_FILTERTEST is *NOT* evaluated. Only *other*
conditions are asserted about the state of the candidate set and scoping.
This means the flag SR_FLAG_CAN_SKIP_FILTER_TEST may be incorrectly applied to
sr->sr_flags.
If my memory serves correctly, this then would cause
ldbm_back_next_search_entry_ext ldbm_search.c:1643 to now consider the
candidate set members valid and the filter test is *not* run.
It’s important to note, that the DONT_BYPASS flag is only referenced in these
locations:
ds I0> grep -r -n -e 'BYPASS_FILTER' ldap
ldap/servers/slapd/back-ldbm/ldbm_search.c:164: * In case
SLAPI_BE_FLAG_DONT_BYPASS_FILTERTEST is set,
ldap/servers/slapd/back-ldbm/ldbm_search.c:167:slapi_be_unset_flag(be,
SLAPI_BE_FLAG_DONT_BYPASS_FILTERTEST);
ldap/servers/slapd/back-ldbm/ldbm_search.c:1087:*lookup_returned_allidsp =
slapi_be_is_flag_set(be, SLAPI_BE_FLAG_DONT_BYPASS_FILTERTEST);
ldap/servers/slapd/back-ldbm/idl_common.c:248:slapi_be_set_flag(be,
SLAPI_BE_FLAG_DONT_BYPASS_FILTERTEST);
ldap/servers/slapd/back-ldbm/idl_common.c:252:slapi_be_set_flag(be,
SLAPI_BE_FLAG_DONT_BYPASS_FILTERTEST);
ldap/servers/slapd/back-ldbm/idl_common.c:366:
[389-devel] Re: Groups are not accessible by filter
> On 29 Apr 2019, at 11:53, Anuj Borah wrote: > > @William Brown > > The space did not make any difference . Look at bellow result . > > (Pdb) i > '(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)' > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(i) ^ Because you are using the wrong class. Filter will wrap your call because you are filtering over the set of Accounts, not “generic searching”. If you want to search a group OfUniqueNames, you need: UniqueGroup(…).filter(). Have a look at _mapped_object.py in def filter and youll see it does: def filter(self, search): # This will yield and & filter for objectClass with as many terms as needed. search_filter = _gen_and([self._get_objectclass_filter(),search]) IE, your search of “uniqueMember=…” is then inserted such that: (&(objectClass=groupOfUniqueNames)(uniqueMember=…)) Because you are using Accounts, this is doing: (&(|(objectClass=nsAccount)(objectClass=person)…) (uniqueMember=…)) Which of course won’t find anything in a group, because Accounts are not Groups. So in fact, lib389 is doing exactly the right thing here, by saying “no, your search is not safe or sane, so you don’t get any results”. Lib389 is designed to prevent you making mistakes, and so will error or do nothing in the cases where something is wrong, rather than allow a corruption or odd behaviour to occur. — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[389-devel] Re: Groups are not accessible by filter
@William Brown
The space did not make any difference . Look at bellow result .
(Pdb) i
'(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)'
(Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(i)
[]
(Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, i)
[dn: cn=Accounting Managers,ou=Groups,dc=example,dc=com
cn: Accounting Managers
description: People who can manage accounting entries
objectClass: top
objectClass: groupOfUniqueNames
ou: groups
uniqueMember: cn=Directory Manager
uniqueMember: uid=scarter,ou=People,dc=example,dc=com
uniqueMember: uid=tmorris,ou=People,dc=example,dc=com
uniqueMember: uid=kvaughan,ou=People,dc=example,dc=com
uniqueMember: uid=rdaugherty,ou=People,dc=example,dc=com
uniqueMember: uid=hmiller,ou=People,dc=example,dc=com
, dn: cn=HR Managers,ou=Groups,dc=example,dc=com
cn: HR Managers
description: People who can manage HR entries
objectClass: top
objectClass: groupOfUniqueNames
ou: groups
uniqueMember: cn=Directory Manager
uniqueMember: uid=kvaughan,ou=People,dc=example,dc=com
uniqueMember: uid=cschmith,ou=People,dc=example,dc=com
]
My point of this mail is that we need to make some modification to the
filter module so that it can completely replace search_s , till now we cant
use filter as replacement of search_s. Check out bellow condition also .
topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (|
(nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['cn', 'cn',
'cn'])
topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (|
(nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['*', 'cn'])
And This one .
topo.standalone.search_s(DEFAULT_SUFFIX,
ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.804:=16777216",['attrlist=cn:sn:uid:testUserAccountControl'])
There is no way we can use filter for the above cases .
Regards
Anuj Borah
On Mon, Apr 29, 2019 at 4:41 AM William Brown wrote:
>
>
> > On 26 Apr 2019, at 01:56, Anuj Borah wrote:
> >
> > @Ludwig
> >
> > Under the same condition .
> >
> > Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter('(uniquemember=uid=kvaughan, ou=People,
> dc=example,dc=com)') >>> gives 0 result . (From filter script)
> >
> >
> > (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
> '(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)') >>> gives
> 2 result (From search_s script)
>
>
>
> These filters are not the same. There is a “ “ between , and ou=People.
>
>
> >
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Minimal GDB in buildroot
On Friday, April 26 2019, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot > > == Summary == > Create gdb-minimal package (without XML support, Python > support, Syntax Highlight and such) and switch to it in buildroot. Thanks, Ben, and thanks to Igor as well. > == Owner == > * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:sergiodj|Sergio > Durigan Junior]] > * Email: ignatenkobr...@fedoraproject.org, sergi...@sergiodj.net > > == Detailed Description == > Create subpackage in gdb source package called > gdb-minimal that will contain 2 files: > * /usr/libexec/gdb-minimal — GDB executable built without > optional unneeded features > * /usr/bin/gdb-add-index — Executable script shared with > gdb-headless package (modified to fallback to gdb-minimal if exists) Just a heads-up: the binary will be named "/usr/bin/gdb.minimal". I have already updated the wiki with this information. FWIW, a new version of GDB is building right now on Fedora Rawhide: gdb-8.3.50.20190425-9.fc31 This version will contain the new gdb-minimal package, ready to be used by the buildroot. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ ___ 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 31 Self-Contained Change proposal: Minimal GDB in buildroot
On Sunday, April 28 2019, Miroslav Suchý wrote: > Dne 26. 04. 19 v 23:49 Ben Cotton napsal(a): >> https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot >> >> == Summary == >> Create gdb-minimal package (without XML support, Python >> support, Syntax Highlight and such) and switch to it in buildroot. > > The change will likely affect Mock and will slightly modify its behaviour. > Right now, it seems that I will add `--allowerasing` to dnf command. > > If you are interrested, please join this RFC discussion: > https://github.com/rpm-software-management/mock/issues/251 Hey Miroslav, I just would like to clarify that the change will actually not require any modification from mock's perspective. The final split of the GDB package will work like this: - gdb-minimal will provide /usr/bin/gdb.minimal. - gdb will probide /usr/bin/gdb, and /usr/bin/gdb-add-index (which is the script the buildroot ultimate uses). - /usr/bin/gdb-add-index will check if there's a /usr/bin/gdb.minimal binary available, and use it. Otherwise, it will fallback to /usr/bin/gdb. Therefore, no Conflicts was needed, which means that even if a package being built depends on gdb, no problems should arise. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ ___ 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: License change of R-gsl: GPLv2+ to GPLv3
Elliott Sales de Andrade wrote: > Upstream has made a new release that changes the license from GPLv2+ > to GPLv3. I intend to build this later today. Since its main use and > linkage was to GSL which is GPLv3 only, this is effectively the > license the built work is already under anyway. No more "or any later version" clause? This is going to hurt when the GPLv4 will happen eventually. GSL as a GNU project will switch to it for sure! Kevin Kofler ___ 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
[389-devel] Re: Groups are not accessible by filter
> On 26 Apr 2019, at 01:56, Anuj Borah wrote:
>
> @Ludwig
>
> Under the same condition .
>
> Accounts(topo.standalone, DEFAULT_SUFFIX).filter('(uniquemember=uid=kvaughan,
> ou=People, dc=example,dc=com)') >>> gives 0 result . (From filter
> script)
>
>
> (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
> '(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)') >>> gives 2
> result (From search_s script)
These filters are not the same. There is a “ “ between , and ou=People.
>
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[389-devel] Re: memory leak with dblayer perf counters
> On 26 Apr 2019, at 01:45, Mark Reynolds wrote:
>
>
> On 4/25/19 11:10 AM, Ludwig wrote:
>> Hi,
>>
>>
>> when running ASAN builds I noticed in some tests a memory leak for dblayer
>> perf counters.
>>
>> A closer look showd it happens with an online restore, in this case we have
>> started dblayer in normal mode, then close it, but pass a mode to prevent
>> the cleanup of the perfcounters (this is according to a comment
>> intentionally), then we do the restore which will not touch the perf
>> counters and then start the dblayer again, in normal mode, which just
>> allocates new memory for the perf counters and overwrites the existing ones,
>> which will now be leaked.
>>
>>
>> So how to deal with it:
>>
>> 1] make behaviour as intended by the comment and fix it like:
>>
>> diff --git a/ldap/servers/slapd/back-ldbm/perfctrs.c
>> b/ldap/servers/slapd/back-ldbm/perfctrs.c
>> index 57a8cbc84..c264a7eec 100644
>> --- a/ldap/servers/slapd/back-ldbm/perfctrs.c
>> +++ b/ldap/servers/slapd/back-ldbm/perfctrs.c
>> @@ -34,7 +34,10 @@ perfctrs_init(struct ldbminfo *li
>> __attribute__((unused)), perfctrs_private **re
>> {
>> perfctrs_private *priv = NULL;
>>
>> -*ret_priv = NULL;
>> +if(*ret_priv != NULL) {
>> +/* we already have allocated perf counters, continue to use them */
>> +return;
>> +}
>>
>> /*
>> * We need the perfctrs_private area on all platforms.
>>
>>
>> or 2]
>>
>> keep the behaviour as it is now and cleanup the perf counters if closed
>> before RESTORE ?
>
>
> I like option 1, less freeing and allocating…
I see no issue with option 1, unless there is a need to reset the perf counters
after a restore ….
>
>>
>>
>> Regards,
>>
>> Ludwig
>> ___
>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>> To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[Bug 1701654] perl-SNMP-Info-3.68 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1701654 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-SNMP-Info-3.67 is |perl-SNMP-Info-3.68 is |available |available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 3.68 Current version/release in rawhide: 3.66-1.fc31 URL: http://search.cpan.org/dist/SNMP-Info/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3318/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: dropping autogenerated dependency on pkg-config
On Sun, Apr 28, 2019 at 4:57 PM Zbigniew Jędrzejewski-Szmek wrote: > > Hi everyone, > > currently, we autogenerate a dependency on pkg-config for all rpms > that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" > returns 4632 entries on my laptop. > > This has always felt backward to me: those packages *provide* something > that is used by pkg-config, they don't *require* pkg-config for anything. > As an analogy, packages with headers are read by a C compiler, but > we don't make them require gcc, and if a package ships an .so file, we > don't add a dependency on the linker to it. Instead, anything which wants > to consume .pc files should simply depend on the tools that consume those > files (pkg-config, pkgconf, or a custom re-implementation). > > Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config > (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh). > > Note: autogenerated Provides/Requires like pkgconfig(foo) are not > part of this proposal. > > Advantages: > - less entries in the dependency graph > - removal of illogical dependency > - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, > libpkgconf) > (Those packages are small, maybe 200k together so this isn't a strong >reason.) > > Disadvantages: > - stuff that uses pkg-config or pkgconf will need to grow a dependency > (e.g. meson which invokes /usr/bin/pkg-config internally). > so there will be some churn. > I've worked in distributions that have implemented this policy, and it's often much more frustrating to work with because of it. It's not always obvious that pkgconfig missing is the reason why stuff doesn't build or otherwise work correctly. I'm pretty sure the reason for having the auto-generated requirement on pkg-config was to make it easy and obvious to use stuff through pkgconfig. I'm personally not in favor of doing this. I know that recently there has been this kick to shrink the default buildroot and minimize the dependency chain in extreme ways. I'm fairly certain a chunk of this has to do with RHEL modularity, but there's also the obvious bit of speeding up buildroot construction. But to be honest, this isn't a significant drain on the dep chain (if we still had the other pkgconfig implementation, it might be, since that pulled in glib2 in the minimal tree). If the problem is pkgconf-m4, I could be persuaded to drop pkgconf-pkg-config's requirement on it. I kept it there principally because the old pkgconfig package had the m4 file in there too. The impact is minimal, it's a developer-side dependency anyway, and it's often useful to have. So from my point of view, I don't see a problem with it. And the dependency generator already makes it "/usr/bin/pkg-config", so you could theoretically swap it with any other conforming implementation. In the end, I don't see any reasonable benefit for doing this, and it just makes developer and packaging work more frustrating. Also, w.r.t. so files, we _do_ pull in the linker library. The library "ld-linux-$ARCH.so.$SOMAJOR" is always pulled in by every rpm containing a library. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
dropping autogenerated dependency on pkg-config
Hi everyone, currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop. This has always felt backward to me: those packages *provide* something that is used by pkg-config, they don't *require* pkg-config for anything. As an analogy, packages with headers are read by a C compiler, but we don't make them require gcc, and if a package ships an .so file, we don't add a dependency on the linker to it. Instead, anything which wants to consume .pc files should simply depend on the tools that consume those files (pkg-config, pkgconf, or a custom re-implementation). Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh). Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal. Advantages: - less entries in the dependency graph - removal of illogical dependency - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.) Disadvantages: - stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn. Zbyszek ___ 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 31 Self-Contained Change proposal: Minimal GDB in buildroot
On Fri, 26 Apr 2019 at 22:59, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot
>
> == Summary ==
> Create gdb-minimal package (without XML support, Python
> support, Syntax Highlight and such) and switch to it in buildroot.
>
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:sergiodj|Sergio
> Durigan Junior]]
> * Email: ignatenkobr...@fedoraproject.org, sergi...@sergiodj.net
>
> == Detailed Description ==
> Create subpackage in gdb source package called
> gdb-minimal that will contain 2 files:
> * /usr/libexec/gdb-minimal — GDB executable built without
> optional unneeded features
> * /usr/bin/gdb-add-index — Executable script shared with
> gdb-headless package (modified to fallback to gdb-minimal if exists)
>
Hi Ben,
AFAIK that part of the gdb is used only to separate debuginfo in
%post_install.
Some times ago IIRC for exactly the same operation was used eu-strip used
-o to save stripped part in debuginfo files.
Even if eu-strip is not doing stripping correctly better would be better to
fix it or modify binutils strip to implement -o option from elfutils strip.
Using gdb for saving debuginfo looks like overkill and elfutils is +10
smaller and depends only on glibc.
$ rpm -q --qf "%{NAME}\t%{SIZE}\n" gdb-headless elfutils
gdb-headless 18123356
elfutils 1245125
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: PYTEST.pyc files
On Fri, 26 Apr 2019, Orion Poplawski wrote:
It appears that in at least some situations pytest will create -PYTEST.pyc
files, and sometimes (always?) with weird permissions:
-rw---. 1 root root 1614 Jul 13 2018
/usr/lib64/python3.7/site-packages/cytoolz/__pycache__/utils_test.cpython-37-PYTEST.pyc
I've noticed the following packages have them:
pytest-4.4.1-1.fc31.src.rpm
python-astropy-healpix-0.4-1.fc31.src.rpm
python-cytoolz-0.9.0.1-3.fc30.src.rpm
python-healpy-1.12.9-1.fc31.src.rpm
python-pytest-repeat-0.8.0-1.fc31.src.rpm
python-pytest-rerunfailures-6.0-1.fc31.src.rpm
python-pytest-shutil-1.6.0-2.fc31.src.rpm
python-reproject-0.4-6.fc30.src.rpm
python3-pytest-asyncio-0.10.0-1.fc31.src.rpm
scipy-1.2.1-1.fc31.src.rpm
These can be prevented by setting PYTHONDONTWRITEBYTECODE=1 when run pytest.
Can anyone else shed more light on this? Should we add this to the
guidelines? (Possibly not since there do not appear to be many packages like
this). I suspect it comes in when has to set
PYTHONPATH=%{buildroot}%{python3_sitearch} due to needing to load compiled
modules.
I usually just run tests with PYTHONDONTWRITEBYTECODE=1 to prevent pytest
from creating its bytecode files as I don't want them to be packaged and
it seems a bit easier than deleting them all after the fact.
Scott
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Modular packages and Python 3.8 rebuild
On 4/26/19 8:01 AM, Miro Hrončok wrote:
The following modular packages require Python 3.7 on Fedora 30:
$ dnf repoquery --releasever 30 --repo=fedora-modular
--repo=updates{,-testing}-modular --whatrequires
'libpython3.7m.so.1.0()(64bit)'
python3-pygit2-0:0.27.4-1.module_f30+2959+693db98d.x86_64
meson-0.50.1-1.module_f31+3967+781a4e9d.src.rpm
$ dnf repoquery --releasever 30 --repo=fedora-modular
--repo=updates{,-testing}-modular --whatrequires 'python(abi) = 3.7'
meson-0:0.50.0-1.module_f30+3586+7354b37a.noarch
meson-0:0.50.1-1.module_f30+3966+49c83da1.noarch
python3-aexpect-0:1.5.1-4.module_f30+2883+7f6a800a.noarch
python3-pygit2-0:0.27.4-1.module_f30+2959+693db98d.x86_64
stratis-cli-0:1.0.2-1.module_f30+3525+55cfb91a.x86_64
That's:
python-pygit2-0.27.4-1.module_f30+2959+693db98d.src.rpm
meson-0.50.0-1.module_f30+3586+7354b37a.src.rpm
meson-0.50.1-1.module_f30+3966+49c83da1.src.rpm
python-aexpect-1.5.1-4.module_f30+2883+7f6a800a.src.rpm
python-pygit2-0.27.4-1.module_f30+2959+693db98d.src.rpm
stratis-cli-1.0.2-1.module_f30+3525+55cfb91a.src.rpm
I have no idea how to query rawhide, because i only get nothing provides
module(platform:f31) errors when I try to set releasever to 31 or to
query --repo=rawhide-modular.
FWIW - on my rawhide system I also see python-avocado.
I'm certainly not an expert, but your questions sparked my curiosity so
I tried to investigate as well.
I'd like to know what shall I do about Python 3.8 rebuilds of those.
How do I do it? Where do I do it?
The first step would be to figure out what module a package comes from.
dnf info/list does not currently appear to work. There is a bug for
this here: https://bugzilla.redhat.com/show_bug.cgi?id=1480569
You can get it by trying to install the package and seeing what module
gets activated:
# dnf install meson
Last metadata expiration check: 0:05:43 ago on Sun 28 Apr 2019 01:18:21
PM MDT.
Dependencies resolved.
===
PackageArchitecture Version
Repository Size
===
Installing:
meson noarch
0.50.1-1.module_f31+3967+781a4e9d rawhide-modular 837 k
Installing dependencies:
ninja-buildx86_64 1.9.0-1.module_f31+3361+bdb2aa23
rawhide-modular 126 k
vim-filesystem noarch 2:8.1.1137-1.fc31
rawhide 29 k
Enabling module streams:
meson latest
ninja latest
So presumably it comes from the meson module.
To rebuild a module (say meson) you would do:
- first rebuild (or at least push the changes to) the meson package, so
that the module-build system picks up the change
- then rebuild the meson module:
fedpkg clone modules/meson
cd meson
git commit -a -m 'rebuild for python 3.8' --allow-empty
git push
fedpkg module-build
Now, I have no idea if modules can interact with side tags at all.
How do I test it against my copr before we proceed in a rawhide side tag?
Note that there's nothing particularly special about the module build of
the package vs the normal build of the package. If the meson package
builds against python3.8 in your copr, it should build find as part of
the module build.
Should I just fetch the srpms and use them as they are? Will they build?
Do I have all their build dependencies? How can I tell without trying?
Your check for what requires the python abi seems like to should be
sufficient to determine what needs building for python 3.8.
How do I cc their maintainers?
Does -maintain...@fedoraproject.org include the maintainers
of the modular build?
So many questions. Can somebody please help me handle those?
Excellent questions...
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
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
[Bug 1703830] New: perl-ExtUtils-MakeMaker-7.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703830 Bug ID: 1703830 Summary: perl-ExtUtils-MakeMaker-7.36 is available Product: Fedora Version: rawhide Status: NEW Component: perl-ExtUtils-MakeMaker Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 7.36 Current version/release in rawhide: 7.34-419.fc30 URL: http://search.cpan.org/dist/ExtUtils-MakeMaker/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2867/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Fedora Rawhide-20190428.n.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Compose FAILS proposed Rawhide gating check! 2 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 9/146 (x86_64), 2/23 (i386), 1/2 (arm) ID: 392869 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/392869 ID: 392879 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/392879 ID: 392901 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/392901 ID: 392902 Test: x86_64 Workstation-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/392902 ID: 392905 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/392905 ID: 392917 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/392917 ID: 392919 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/392919 ID: 392920 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/392920 ID: 392926 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/392926 ID: 392979 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/392979 ID: 392992 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/392992 ID: 393017 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/393017 Soft failed openQA tests: 8/146 (x86_64), 3/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 392880 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/392880 ID: 392881 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/392881 ID: 392882 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/392882 ID: 392891 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/392891 ID: 392900 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/392900 ID: 392904 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/392904 ID: 392940 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/392940 ID: 392942 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/392942 ID: 392943 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/392943 ID: 392944 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/392944 ID: 393000 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/393000 Passed openQA tests: 129/146 (x86_64), 18/23 (i386) Skipped non-gating openQA tests: 1 of 171 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: Orphaning js-jquery
On Sat, 27 Apr 2019 11:12:48 -0700 Kevin Fenzi wrote: > On 4/26/19 8:53 AM, stan wrote: > > On Fri, 26 Apr 2019 11:07:54 - (UTC) > > Petr Pisar wrote: > > > > I am a fedora user with no dog in this fight. > > > >> Controversial property of modules are private build-time > >> dependencies. Modularity allows packagers to hide them and to not > >> to support them (to the extend that they work in my module). > >> However, this privatisation has costs. It means duplication of > >> work unless two ... > > > > Isn't this contrary to the Fedora rules? If I'm understanding this > > correctly, it means that modules in Fedora can contain dependencies > > on code that isn't available, so that Fedora (and users) can't > > build that module from source. > > No. The code is available at src.fedoraproject.org for everything. > The binary packages may not be available outside the module build > system, depending on how things are setup. > > > And that the module could contain basically > > anything because no one can examine the contents that built the > > module. Could someone privately pull in something like the > > proprietary nvidia binary blob and use it to build their module > > without anyone knowing? > > No more so than any packager could just add the nvidia binary blob to > their package. ie, sure, but we trust our maintainers not to do that, > and if we detected it likely the maintainer wouldn't be a maintainer > anymore. > > > > Because I'm not knowledgeable about this, it might be that private > > dependencies have to be packages built from source code available > > in the Fedora ecosystem, and so this is not possible. I just want > > to clarify my understanding. > > Yes, they are all still built from source. Thanks. ___ 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: Orphaning js-jquery
On Sat, 27 Apr 2019 11:19:06 -0400 Neal Gompa wrote: > The restrictions by Fedora Koji prevent that, but yes, MBS and > Modularity do allow for something like this. It can't happen in Fedora > because our Koji is not set up to consume external repositories > (except for EPEL, which consumes RHEL content this way). > > But I don't know if this restriction will stick around in the > future... > > That said, today, modules can and do rely on unpublished RPMs that > have packaging in Dist Git. It is currently impossible with some > modules to be able to privately rebuild them outside of Fedora > infrastructure. I've made my displeasure about this known in the past, > and hopefully this will be rectified soon. Thanks. ___ 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
[Bug 1703626] perl-Module-Faker-0.022 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703626 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Module-Faker-0.021 is |perl-Module-Faker-0.022 is |available |available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 0.022 Current version/release in rawhide: 0.020-4.fc30 URL: http://search.cpan.org/dist/Module-Faker/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6989/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190428.n.0 changes
OLD: Fedora-Rawhide-20190427.n.0 NEW: Fedora-Rawhide-20190428.n.0 = SUMMARY = Added images:3 Dropped images: 7 Added packages: 12 Dropped packages:1 Upgraded packages: 31 Downgraded packages: 1 Size of added packages: 7.39 MiB Size of dropped packages:159.41 KiB Size of upgraded packages: 2.62 GiB Size of downgraded packages: 841.69 KiB Size change of upgraded packages: 2.31 MiB Size change of downgraded packages: -8 B = ADDED IMAGES = Image: Minimal raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20190428.n.0.aarch64.raw.xz Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20190428.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20190428.n.0.s390x.tar.xz = DROPPED IMAGES = Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190427.n.0.s390x.vmdk Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190427.n.0.s390x.raw.xz Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20190427.n.0.x86_64.vagrant-virtualbox.box Image: Workstation live i386 Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-Rawhide-20190427.n.0.iso Image: Astronomy_KDE live i386 Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20190427.n.0.iso Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20190427.n.0.x86_64.vagrant-libvirt.box Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190427.n.0.s390x.qcow2 = ADDED PACKAGES = Package: rust-chrono-humanize-0.0.11-1.fc31 Summary: Human-friendly time expressions RPMs:rust-chrono-humanize+default-devel rust-chrono-humanize+pedantic-devel rust-chrono-humanize-devel Size:34.32 KiB Package: rust-docmatic-0.1.2-1.fc31 Summary: Test Rust examples in your documentation RPMs:rust-docmatic+default-devel rust-docmatic-devel Size:25.25 KiB Package: rust-lscolors-0.5.0-1.fc31 Summary: Colorize paths using the LS_COLORS environment variable RPMs:lscolors rust-lscolors+ansi_term-devel rust-lscolors+default-devel rust-lscolors-devel Size:808.78 KiB Package: rust-lsd-0.14.0-1.fc31 Summary: ls command with a lot of pretty colors and some other stuff RPMs:lsd Size:2.18 MiB Package: rust-openssh-keys-0.4.1-1.fc31 Summary: Read and write OpenSSH public keys RPMs:rust-openssh-keys+default-devel rust-openssh-keys-devel Size:32.68 KiB Package: rust-pnet_datalink-0.22.0-1.fc31 Summary: Cross-platform, datalink layer networking RPMs:rust-pnet_datalink+default-devel rust-pnet_datalink+netmap-devel rust-pnet_datalink+netmap_sys-devel rust-pnet_datalink+pcap-devel rust-pnet_datalink-devel Size:56.56 KiB Package: rust-serde-xml-rs-0.3.1-1.fc31 Summary: xml-rs based deserializer for Serde (compatible with 0.9+) RPMs:rust-serde-xml-rs+default-devel rust-serde-xml-rs+legacy-support-devel rust-serde-xml-rs+with-backtrace-devel rust-serde-xml-rs-devel Size:45.57 KiB Package: rust-silver-1.0.5-1.fc31 Summary: Cross-shell customizable powerline-like prompt with icons RPMs:silver Size:4.12 MiB Package: rust-simple_logger-1.0.1-1.fc31 Summary: Logger that prints all messages with a readable output format RPMs:rust-simple_logger+default-devel rust-simple_logger-devel Size:17.52 KiB Package: rust-slog-async-2.3.0-1.fc31 Summary: Asynchronous drain for slog-rs RPMs:rust-slog-async+default-devel rust-slog-async+dynamic-keys-devel rust-slog-async+nested-values-devel rust-slog-async-devel Size:42.82 KiB Package: rust-slog-term-2.4.0-1.fc31 Summary: Unix terminal drain and formatter for slog-rs RPMs:rust-slog-term+default-devel rust-slog-term-devel Size:33.36 KiB Package: rust-terminal_size-0.1.8-1.fc31 Summary: Gets the size of your Linux or Windows terminal RPMs:rust-terminal_size+default-devel rust-terminal_size-devel Size:22.94 KiB = DROPPED PACKAGES = Package: python-cpopen-1.5-7.fc28 Summary: Creates a sub-process in simpler safer manner RPMs:python2-cpopen Size:159.41 KiB = UPGRADED PACKAGES = Package: PySolFC-2.6.4-2.fc31 Old package: PySolFC-2.6.4-1.fc31 Summary: A collection of solitare card games RPMs: PySolFC Size: 4.60 MiB Size change: 212 B Changelog: * Sun Apr 28 2019 S??rgio Basto - 2.6.4-2 - Sound fix, seems using SOUND_MOD=auto it works Package: ant-1.10.5-5.fc31 Old package: ant-1.10.5-4.fc30 Summary: Java build tool RPMs: ant ant-antlr ant-apache-bcel ant-apache-bsf ant-apache-log4j ant-apache-oro ant-apache-regexp ant-apache-resolver ant-apache-xalan2 ant-commons-logging ant-commons-net ant-javadoc ant-javamail ant-jdepend ant-jmf ant-jsch ant-junit ant-junit5 ant-lib ant-manual ant-swing ant
Re: Fedora 31 Self-Contained Change proposal: Minimal GDB in buildroot
When I was filing mock's issue, I was still discussing how we can implement this in GDB. This particular change does not require any mock / config changes. gdb-minimal will not conflict with gdb.. Although that mock feature is useful on its own if we ever decide to replace libcurl with libcurl-minimal and such for build environment. On Sun, Apr 28, 2019 at 3:59 PM Miroslav Suchý wrote: > Dne 26. 04. 19 v 23:49 Ben Cotton napsal(a): > > https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot > > > > == Summary == > > Create gdb-minimal package (without XML support, Python > > support, Syntax Highlight and such) and switch to it in buildroot. > > The change will likely affect Mock and will slightly modify its behaviour. > Right now, it seems that I will add `--allowerasing` to dnf command. > > If you are interrested, please join this RFC discussion: > https://github.com/rpm-software-management/mock/issues/251 > > Miroslav > ___ > 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 > ___ 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 31 Self-Contained Change proposal: Minimal GDB in buildroot
Dne 26. 04. 19 v 23:49 Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot > > == Summary == > Create gdb-minimal package (without XML support, Python > support, Syntax Highlight and such) and switch to it in buildroot. The change will likely affect Mock and will slightly modify its behaviour. Right now, it seems that I will add `--allowerasing` to dnf command. If you are interrested, please join this RFC discussion: https://github.com/rpm-software-management/mock/issues/251 Miroslav ___ 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
[Bug 1703790] perl-YAML-1.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703790 Paul Howarth changed: What|Removed |Added Fixed In Version||perl-YAML-1.28-1.fc31 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1703790] perl-YAML-1.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703790 --- Comment #2 from Fedora Update System --- perl-YAML-1.28-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1911b73cee -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1703790] perl-YAML-1.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703790 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- perl-YAML-1.28-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb2c321d46 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1703667] perl-Getopt-Long-Descriptive-0.104 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703667 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Getopt-Long-Descriptiv ||e-0.104-1.fc31 Resolution|--- |RAWHIDE Last Closed||2019-04-28 12:19:06 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=34507765 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1703790] New: perl-YAML-1.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703790 Bug ID: 1703790 Summary: perl-YAML-1.28 is available Product: Fedora Version: rawhide Status: NEW Component: perl-YAML Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.28 Current version/release in rawhide: 1.27-2.fc30 URL: http://search.cpan.org/dist/YAML/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3547/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1703782] New: perl-Inline-0.83 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703782 Bug ID: 1703782 Summary: perl-Inline-0.83 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Inline Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, caol...@redhat.com, jples...@redhat.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.83 Current version/release in rawhide: 0.82-1.fc31 URL: http://search.cpan.org/dist/Inline/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2984/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1703758] New: perl-Devel-PPPort-3.47 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703758 Bug ID: 1703758 Summary: perl-Devel-PPPort-3.47 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Devel-PPPort Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.47 Current version/release in rawhide: 3.45-2.fc31 URL: http://search.cpan.org/dist/Devel-PPPort/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5760/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1703622] perl-Mojolicious-8.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703622 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Mojolicious-8.15-1.fc3 ||1 Resolution|--- |RAWHIDE Last Closed||2019-04-28 06:46:15 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1259643 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1703266] perl-Catalyst-Manual-5.9010 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703266 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Catalyst-Manual-5.9010 ||-1.fc31 Resolution|--- |RAWHIDE Last Closed||2019-04-28 06:41:51 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1259644 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
