Re: Modularity vs. libgit
I think the best option is to create non-modular compat packages. In my opinion, modularity makes sense for end user applications, but I'm not sure what benefits it has for libraries. Libraries tend to work well as compat packages, so I implemented this in copr to try it out. * https://copr.fedorainfracloud.org/coprs/carlwgeorge/parallel-libgit2/ * https://copr-be.cloud.fedoraproject.org/results/carlwgeorge/parallel-libgit2/fedora-rawhide-x86_64/00935643-libgit2_0.26/libgit2_0.26.spec * https://copr-be.cloud.fedoraproject.org/results/carlwgeorge/parallel-libgit2/fedora-rawhide-x86_64/00935642-libgit2_0.27/libgit2_0.27.spec This copr allows the following non-modular packages to be installed at the same time: * Rawhide * libgit2 0.28.2 * libgit2_0.27 0.27.8 * libgit2_0.26 0.26.8 * Fedora 30 * libgit2 0.27.8 * libgit2_0.26 0.26.8 These packages follow the current naming and conflict packaging guidelines. * https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple * https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_compat_package_conflicts If I'm missing anything about the benefits of a modular libgit2 help me understand. Given the current issues, this seems like a reasonable solution. If other agree, I'm happy to submit these compat packages for review. Carl George Rackspace ___ 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: Modularity vs. libgit
After reading the bug report and the discussions, I still don't understand why dnf is complaining about a conflict with packages (modules?) that are not installed and are not even trying to be installed. Can someone explain that? ___ 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] 389 DS nightly 2019-06-14 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/06/14/report-389-ds-base-1.4.1.3-20190613git054d32e.fc30.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
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following builds have been pushed to Fedora EPEL 6 updates-testing R-littler-0.3.8-1.el6 php-phpseclib-2.0.18-1.el6 Details about builds: R-littler-0.3.8-1.el6 (FEDORA-EPEL-2019-f3bdf18841) littler: R at the Command-Line via 'r' Update Information: Version 0.3.8. ChangeLog: * Thu Jun 13 2019 Mattias Ellert - 0.3.8-1 - New upstream release 0.3.8 php-phpseclib-2.0.18-1.el6 (FEDORA-EPEL-2019-537ea92f59) PHP Secure Communications Library Update Information: **Version 2.0.18** - 2019-06-13 - SSH2: close channel when a timeout occurs (#1378) - SFTP: improve handling of malformed packets (#1371) - RSA: add support for OpenSSH private keys (#1372) ChangeLog: * Thu Jun 13 2019 Remi Collet - 2.0.18-1 - update to 2.0.18 ___ 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
Fedora testing-20190614.0 compose check report
Missing expected images: Atomichost qcow2 x86_64 Atomichost raw-xz x86_64 Passed openQA tests: 2/2 (x86_64) -- 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
Fedora updates-20190614.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Failed openQA tests: 1/2 (x86_64) New failures (same test not failed in updates-20190613.0): ID: 411670 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/411670 Passed openQA tests: 1/2 (x86_64) -- 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: Any new restriction in Koji added recently in Rawhide?
On Thu, 2019-06-13 at 17:02 +0100, Sérgio Basto wrote: > On Thu, 2019-06-13 at 13:03 +0200, Peter Lemenkov wrote: > > Hello! > > > > чт, 13 июн. 2019 г. в 12:49, Petr Pisar : > > > On 2019-06-13, Peter Lemenkov wrote: > > > > I've noticed that I cannot build Elixir in Rawhide anymore. It > > > > got > > > > stuck at tests and all I've got is a cryptic (at least to me) > > > > message: > > > > > > > > > > > > + RPM_EC=0 > > > > BUILDSTDERR: ++ jobs -p > > > > + exit 0 > > > > > > > F31 has a new rpm-build with a new features. Your issue seems > > > like > > > another bug in the same process clean-up code I reported an hour > > > ago. > > > See bug #1720143. > > > > Yes, looks exactly like my case. Thanks for the pointing out! > > Is fixed for me I mixed my builds, I still have issues with libprojectM [1] , but seems a little different that is reported [2] [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=35530649 [2] + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip BUILDSTDERR: xargs: unmatched single quote; by default quotes are special to xargs unless you use the -0 option BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.ojGFZw (%install) BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.ojGFZw (%install) tM-3.1.1-0.6.rc4.fc31.x86_64/usr/lib64/libprojectM.so.3.1.1 > Best regards, > -- > Sérgio M. B. > ___ > 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 -- Sérgio M. B. ___ 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: Octave 4.4 update coming soon to rawhide
On Tue, 2018-12-04 at 15:59 +, Sérgio Basto wrote: > Hi, > > Since Octave is not a core package I agree with update it for F29 . > > I'd like also update opencv in F29 from 3.4.1 to 3.4.4 but due > possible ABI breakage [1]. > For that I need a proven package that rebuild all dependent software > > Also about math and related software we have update of vtk and TBB > (thread "Yet another gargantuan > mathematical software update" ) > > I'd like at least bring all these software to F29 in a copr repo , > I'm using my repo [2] > > Also I will try enable octave bindings for opencv . I checked this (enable octave bindings for opencv) yestarday we need mex compiler package [1] [1] https://www.mathworks.com/help/vision/ug/opencv-interface.html https://kyamagu.github.io/mexopencv/ > Thanks. > > > > [1] > https://bugzilla.redhat.com/show_bug.cgi?id=1572611 > > dist.abicheck FAILED for opencv-3.4.3-1.fc30 > https://taskotron.fedoraproject.org/artifacts/all/a91339ea-c218-11e8-8509-525400fc9f92/tests.yml/opencv-3.4.3-1.fc29.log > > dist.abicheck FAILED for opencv-3.4.4-1.fc30 > https://taskotron.fedoraproject.org/artifacts/all/a4e89fb2-f676-11e8-ab25-525400fc9f92/tests.yml/opencv-3.4.4-1.fc30.log > > [2] > https://copr.fedorainfracloud.org/coprs/sergiomb/opencv/builds/ > > On Tue, 2018-12-04 at 16:09 +0300, Vascom wrote: > > What about Octave 4.4. for F29? > > пн, 12 нояб. 2018 г. в 03:51, Orion Poplawski : > > > I've planning on building octave 4.4 soon (next day or two) in > > > rawhide. > > > I've been building dependent packages here: > > > > > > https://copr.fedorainfracloud.org/coprs/g/scitech/octave4.4/package > > > s/ > > > > > > Anyone in the scitech group can submit builds there if needed. > > > > > > Notes on needed changes to packages are here: > > > > > > https://docs.google.com/spreadsheets/d/1bBEe4Ng3TBUh-EWOQTZt_SvbBYo > > > KWgrC-qH5VOggG_M/edit?usp=sharing > > > > > > I'm going to start working on PRs for the various changes for > > > maintainers to review. Of note: > > > > > > - swig requires updating to a git snapshot to get octave 4.4 > > > support > > > - pfstools needs an update to 2.1.0 > > > - NLopt updated to 2.5.0 - switches to using cmake > > > > > > Orion > > > > > > -- > > > 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/ > > > ___ > > > 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_guidel > > > ines > > > 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_guidelin > > es > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@li > > sts.fedoraproject.org > -- > Sérgio M. B. > ___ > 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 -- Sérgio M. B. ___ 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] Bodhi 4 in EPEL 7
Greetings! Fedora Infrastructure recently deployed Bodhi 4.0.0 to production, which included quite a few backwards incompatible changes[0]. Some of the changes have resulted in older Bodhi clients (less than 4.0.0) not being compatible with the new version of the server. In Fedora, FESCo decided to allow the Bodhi 4.0.0 update to go to Fedora 29 and 30, and for us to add a bodhi3 compat client package in case there were any users counting on using the bodhi3 client with a non-Fedora Bodhi server[1] (believe it or not, there are other Bodhi deployments out there!) EPEL 7 currently has a fairly old Bodhi version (2.11.0). This version is also not compatible with the Bodhi 4 server. What do you think about upgrading Bodhi in EPEL 7 as well? There are a few things I'd like to highlight for consideration here: * Bodhi 4 is Python 3 only. Bodhi 2 is Python 2 only. So, upgrading to Bodhi 4 isn't just a switch to a newer Bodhi, it will also mean a switch in Python versions. This will affect dependencies (there are a few). * I think we might be missing Python 3 dependencies for Bodhi 4. * It might be good to consider dropping the Bodhi server as we do this. EPEL 7 has versions of some of Bodhi's server dependencies that are too old for Bodhi 4. I *think* the client should be OK with the client dependency versions, but of course you never know until you try. * Would we want to maintain a bodhi2 compat package for EPEL 7, analagous to the bodhi3 compat package we made for Fedora? * What about EPEL 6? It's still on Bodhi 0.9, and I have never seen or worked on that codebase. Unfortunately, it has Python 2.6 and not any verison of Python 3, to my knowledge. Anything else you can think of? [0] https://bodhi.fedoraproject.org/docs/user/release_notes.html#v4-0-0 [1] https://pagure.io/fesco/issue/2137 signature.asc Description: This is a digitally signed message part ___ 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
[389-devel] Re: please review: PR 50447 - Revise replication agreement status messages
We have a problem... FreeIPA, as well as other unknown applications, expect the status to be in the old format. While we can fix this in FreeIPA, it will still break older versions of FreeIPA during replica installs when it tries to setup replication with the new version. So all active/supported versions of FreeIPA need a code fix (which I have) and need it to be rebuilt and released before we can change replicaLastUpdateStatus*. *We can still have the new JSON attribute, but the original attribute will have to remain the same. So I need to rework the fix, but the JSON part can still be reviewed. ** On 6/13/19 1:08 PM, Mark Reynolds wrote: https://www.port389.org/docs/389ds/design/repl-agmt-status-design.html https://pagure.io/389-ds-base/pull-request/50447 ___ 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
[Bug 1720382] New: perl-XXX-0.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1720382 Bug ID: 1720382 Summary: perl-XXX-0.33 is available Product: Fedora Version: rawhide Status: NEW Component: perl-XXX Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.33 Current version/release in rawhide: 0.32-3.fc31 URL: http://search.cpan.org/dist/XXX/ 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/3546/ -- 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: Modularity vs. libgit
Hello Adam and everyone else, I want to point out that there are 2 issues and not just one as described in the article. 1) Default streams can't conflict 2) Switching dependencies on a module does not work Both of the issues are solvable and should be handled by DNF, however they are not. And I could not get any ETA on fixing that. So the article talks about second issue. I'll comment on it first and then I'll talk more about first issue. # One stream with compatibility packages This is not entirely doable. While library itself can be installed in parallel, the devel package can not. So this would mean I would either have to ship only one devel package which would not make sense or do terrible hacks to install them in parallel (like mangling /usr/include directory, pkg-config and such) and it won't work correctly. And after all, what is the advantage of modularity in this case? I can do the same in traditional Fedora. # New streams of silver and bat So we will have then silver:rolling, silver:rolling-new, silver:rolling-very-new and such? Note that I simply can't support old streams. They would need to go EOL as soon as I create new one. And we decided not to do. Streams must be supported by people within active Fedora release. So this is not solution to a problem at all. # Bundle libgit into the silver and bat modules Yes, I can link libgit2 statically everywhere. I don't even have to include that package, I just have to ship static version of libgit2. The problem here is that since in Fedora we don't have any automation for rebuilding modules / packages, every time something changes in libgit2, I would have manually go, check what to rebuild and do that rebuilds. # Potential solutions for the future So we don't even look at solution named "Just Fix DNF"? Now to the problem which was not described in the article.. In order to describe, I'll start in short points what was before and what has changed. * Fedora 29 and 30 have non-modular libgit2-0.27 * Fedora 31 has had non-modular libgit2-0.27 as well, but last or this week has upgraded to libgit2-0.28 * All Fedora versions ship 0.26, 0.27 and 0.28 streams of libgit2 as a modules * All Fedora versions have default stream set to match non-modular version (due to not having Ursa Prime ready) * silver, bat, exa and more modules have default stream and used to depend on libgit2:0.27 and have been rebuilt (most of them) to depend on libgit2:0.28 Here I should introduce what "default stream" means for users. Users should be able to just do "dnf install silver" and that should enable default stream of module which provides package "silver". That means, until you do installation, they can conflict. It might be not very nice for users, but this is valid. So if we have default tokei:rolling which depends on libgit2:0.27 and default libgit2:0.28, you should be able to install either tokei which would install libgit2:0.27 or if you do "dnf install libgit2", it would install 0.28 and you won't be able to install tokei. What happens today is DNF just always complains and does not allow you to install an operating system. So simply untagging new builds of modules won't help, because then modules will start depending back on libgit2:0.27 while rawhide has already default for libgit2:0.28. Neither you can change a default back to 0.27 because non-modular libgit2 has been upgraded and all packages were rebuilt. There are 2 solutions for this problem (not including fix of DNF): 1) Unset all defaults for Rust applications. This will solve problem of not being to install an OS, but it won't solve issue with upgrades. 2) Untag new builds for Fedora 29 and 30, stop shipping updates for Rust applications there and let them rot. For rawhide, I can rebuild last few modules to start depending on libgit2:0.28, so rawhide will be back on track. First option is just horrible. Second one is okay-ish, but before this way would be chosen I want to hear what is the ETA for fixing these DNF bugs. I do not want Rust applications just rot in stable releases. On Thu, Jun 13, 2019 at 9:22 PM Adam Samalik wrote: > > So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With a > help of a few people, I've put together this post to get us on common ground: > https://communityblog.fedoraproject.org/modularity-vs-libgit/ > > There are few ideas about solving the issue right now. But we might be able > to think about better ways to deal with similar issues long-term. Let's do > this! > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1717117 > [2] https://pagure.io/fesco/issue/2146#comment-575852 > -- > > Adam Šamalík > --- > Senior Software Engineer > Red Hat > ___ > 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:
Re: Any new restriction in Koji added recently in Rawhide?
On Thu, 2019-06-13 at 12:42 -0400, Neal Gompa wrote:
> > > > This is wrong (not sure if the culprit)
> > > >
> > > > %endif %{__with_rebar3}
> > > >
> > > > I would rewrite it to:
> > > >
> > > > %endif # __with_rebar3
> > >
> > > Actually both are wrong, and rpm >= 4.15 will complain (unlike old
> > > versions). Rpm only supports comments at beginning of line, and this
> > > only ever worked by accident.
> >
> > Oh dear, that's unfortunate. Because of the lack of indentation,
> > parsing a nested set of %ifs in spec files has always been difficult,
> > and adding an end-of-line comment after the %endif to help is
> > definitely a pattern I've seen in multiple spec files.
>
> I guess people don't know you can indent conditional blocks? It's the
> only indentation rpmbuild allows, but you can do it.
Well, I for one sure didn't...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.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: New mailing lists available for podman/libpod
On Thu, Jun 13, 2019 at 3:13 PM Daniel Walsh wrote: > > Send an email to: podman-j...@lists.podman.io with the word "subscribe" > in the title, or by going to https://lists.podman.io and scrolling to > the bottom of that page to subscribe. > Could FAS login be added as a supported auth? -- 真実はいつも一つ！/ 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
Modularity vs. libgit
So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With a help of a few people, I've put together this post to get us on common ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/ There are few ideas about solving the issue right now. But we might be able to think about better ways to deal with similar issues long-term. Let's do this! [1] https://bugzilla.redhat.com/show_bug.cgi?id=1717117 [2] https://pagure.io/fesco/issue/2146#comment-575852 -- Adam Šamalík --- Senior Software Engineer Red Hat ___ 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
New mailing lists available for podman/libpod
Send an email to: podman-j...@lists.podman.io with the word "subscribe" in the title, or by going to https://lists.podman.io and scrolling to the bottom of that page to subscribe. ___ 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 1720328] New: perl-Mail-Box-IMAP4-3.007 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1720328 Bug ID: 1720328 Summary: perl-Mail-Box-IMAP4-3.007 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Mail-Box-IMAP4 Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 3.007 Current version/release in rawhide: 3.006-1.fc31 URL: http://search.cpan.org/dist/Mail-Box-IMAP4/ 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/13812/ -- 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] please review: PR 50447 - Revise replication agreement status messages
https://www.port389.org/docs/389ds/design/repl-agmt-status-design.html https://pagure.io/389-ds-base/pull-request/50447 ___ 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] *** NameError: name 'ds_is_older' is not defined
Hi all,
Issue: https://pagure.io/389-ds-base/issue/50446
from lib389.utils import (ds_is_older) is missing in
https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/idm/account.py
users = UserAccounts(standalone, DEFAULT_SUFFIX)
for i in users.list(): i.dn
'uid=testuser,ou=People,dc=example,dc=com'
'uid=test_user_1000,ou=People,dc=example,dc=com'
'uid=test_user1,ou=People,dc=example,dc=com'
UserAccount(standalone,'uid=test_user1,ou=People,dc=example,dc=com').enroll_certificate('/etc/dirsrv/slapd-standalone1/user-test_user1.der')
*** NameError: name 'ds_is_older' is not defined
Regards
Anuj Borah
___
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: Any new restriction in Koji added recently in Rawhide?
On Thu, Jun 13, 2019 at 12:41 PM Adam Williamson
wrote:
>
> On Thu, 2019-06-13 at 13:25 +0300, Panu Matilainen wrote:
> > On 6/13/19 12:54 PM, Miroslav Suchý wrote:
> > > Dne 13. 06. 19 v 11:43 Peter Lemenkov napsal(a):
> > > > Hello All!
> > > > I've noticed that I cannot build Elixir in Rawhide anymore. It got
> > > > stuck at tests and all I've got is a cryptic (at least to me) message:
> > > >
> > > >
> > > > + RPM_EC=0
> > > > BUILDSTDERR: ++ jobs -p
> > > > + exit 0
> > > >
> > > >
> > > > See this link for full build log:
> > > >
> > > > * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
> > > > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
> > > >
> > > > For comparison here is how successful build log for F-30 looks like
> > > > (the same package)
> > > >
> > > > * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
> > > > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
> > > >
> > > > Are there any differences between Koji settings for Rawhide and F-30
> > > > which we should know about? Selinux, resource constraints etc?
> > > >
> > >
> > > This is wrong (not sure if the culprit)
> > >
> > > %endif %{__with_rebar3}
> > >
> > > I would rewrite it to:
> > >
> > > %endif # __with_rebar3
> >
> > Actually both are wrong, and rpm >= 4.15 will complain (unlike old
> > versions). Rpm only supports comments at beginning of line, and this
> > only ever worked by accident.
>
> Oh dear, that's unfortunate. Because of the lack of indentation,
> parsing a nested set of %ifs in spec files has always been difficult,
> and adding an end-of-line comment after the %endif to help is
> definitely a pattern I've seen in multiple spec files.
I guess people don't know you can indent conditional blocks? It's the
only indentation rpmbuild allows, but you can do it.
--
真実はいつも一つ！/ 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
Re: Any new restriction in Koji added recently in Rawhide?
On Thu, 2019-06-13 at 13:03 +0200, Peter Lemenkov wrote: > Hello! > > чт, 13 июн. 2019 г. в 12:49, Petr Pisar : > > On 2019-06-13, Peter Lemenkov wrote: > > > I've noticed that I cannot build Elixir in Rawhide anymore. It > > > got > > > stuck at tests and all I've got is a cryptic (at least to me) > > > message: > > > > > > > > > + RPM_EC=0 > > > BUILDSTDERR: ++ jobs -p > > > + exit 0 > > > > > F31 has a new rpm-build with a new features. Your issue seems like > > another bug in the same process clean-up code I reported an hour > > ago. > > See bug #1720143. > > Yes, looks exactly like my case. Thanks for the pointing out! Is fixed for me Best regards, -- Sérgio M. B. ___ 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: Any new restriction in Koji added recently in Rawhide?
On Thu, 2019-06-13 at 13:25 +0300, Panu Matilainen wrote:
> On 6/13/19 12:54 PM, Miroslav Suchý wrote:
> > Dne 13. 06. 19 v 11:43 Peter Lemenkov napsal(a):
> > > Hello All!
> > > I've noticed that I cannot build Elixir in Rawhide anymore. It got
> > > stuck at tests and all I've got is a cryptic (at least to me) message:
> > >
> > >
> > > + RPM_EC=0
> > > BUILDSTDERR: ++ jobs -p
> > > + exit 0
> > >
> > >
> > > See this link for full build log:
> > >
> > > * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
> > > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
> > >
> > > For comparison here is how successful build log for F-30 looks like
> > > (the same package)
> > >
> > > * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
> > > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
> > >
> > > Are there any differences between Koji settings for Rawhide and F-30
> > > which we should know about? Selinux, resource constraints etc?
> > >
> >
> > This is wrong (not sure if the culprit)
> >
> > %endif %{__with_rebar3}
> >
> > I would rewrite it to:
> >
> > %endif # __with_rebar3
>
> Actually both are wrong, and rpm >= 4.15 will complain (unlike old
> versions). Rpm only supports comments at beginning of line, and this
> only ever worked by accident.
Oh dear, that's unfortunate. Because of the lack of indentation,
parsing a nested set of %ifs in spec files has always been difficult,
and adding an end-of-line comment after the %endif to help is
definitely a pattern I've seen in multiple spec files.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.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
[Bug 1720287] New: perl-Future-0.41 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1720287 Bug ID: 1720287 Summary: perl-Future-0.41 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Future Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.41 Current version/release in rawhide: 0.40-2.fc31 URL: http://search.cpan.org/dist/Future/ 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/11795/ -- 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
Noarch python provides
Is there any possibility that the new rpmbuild might be responsible for a change from: Provides: python-subunit to: Provides: python-subunit(architecture) in a noarch package? See https://bugzilla.redhat.com/show_bug.cgi?id=1720139. -- Jerry James http://www.jamezone.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
[389-devel] Re: please review: Replication Status Message Improvements
On 6/13/19 4:02 AM, William Brown wrote: On 12 Jun 2019, at 17:36, Mark Reynolds wrote: http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html Looks great! Instead of "Success" we could use "Healthy" because replication isn't a success/fail, it's a longterm "good/bad" IE healthy/failing state. So perhaps instead of success/warning/error, we have "healthy/delayed/warning/error" instead? Additionally, on warning + error, we log those to error log by default so that an admin can "see" past errors, and when they "resolve" a resolution is also posted to the error log too? Really there are only three states: working, delayed, and broken. What about: Good, Warning, Error? FYI if this does not get pushed today we will a very important deadline (in fact it will mean all the bugs slated for the next release will be missed) So I don't want to keep debating "names" for much longer... Date is json should be ISO 8601 format instead? 2019-06-13T07:53:20+00:00 I will look into this, but we are running our of time as I mentioned above. Maybe I will just drop the date for now... I hope this helps! ___ 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 ___ 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: How to create a user with certificate with lib389
On Thu, Jun 13, 2019 at 3:26 PM William Brown wrote: > > Is the test case *just* testing if binary searching of attributes works? The test was to check if we can query the server for userCertificate=, where is a string representation of a base64 encoded x509 certificate. The original test was also passing binary representation (usercertificate;binary=...) to ldapsearch (to see if it translates correctly to base64). -- Viktor ___ 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: How to create a user with certificate with lib389
base64 in ldap is just to transport binary ... so they are one and the same.
Either way, I think that you should check ensure str, and provide logs from
access and lib389 in verbose to show what the filter generator is doing,a nd
what the server is attempting to process so we can see where the errors are
being introduced into the filter,
> On 13 Jun 2019, at 15:41, Anuj Borah wrote:
>
> Main aim of the test case is filter user with binary search not the base64 .
>
> (Pdb) six.ensure_str(crt)
> *** UnicodeDecodeError: 'utf-8' codec can't decode byte 0x82 in position 1:
> invalid start byte
>
> On Thu, Jun 13, 2019 at 7:05 PM William Brown wrote:
> I'm really suspicious here that your escape bytes is not needed for ldap as
> much as to prevent python state leaking into the string and the data. I'm
> wondering if there is a better approach
>
> Can ldap filters take base64 instead? Perhaps the issue with your filter atm
> is that you are putting a byte string into an f string so that formats with
> escapes. Have you tried ensure_str() instead?
>
>
>
> > On 13 Jun 2019, at 15:29, Anuj Borah wrote:
> >
> > Yes, it is. but with escape_bytes function only.
> >
> > (Pdb) Accounts(standalone,
> > DEFAULT_SUFFIX).filter(f"(userCertificate={crt})")
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
> > 'No such file or directory'}
> >
> > And finally .
> > Accounts(standalone,
> > DEFAULT_SUFFIX).filter(f"(userCertificate={escape_bytes(crt)})") >>>
> > escape_bytes(this is function i want to put in utils.py)
> > []
> >
> >
> >
> > On Thu, Jun 13, 2019 at 6:56 PM William Brown wrote:
> > Is the test case *just* testing if binary searching of attributes works?
> >
> > > On 13 Jun 2019, at 15:25, Anuj Borah wrote:
> > >
> > > @William Brown
> > >
> > >
> > > This is my test case in bash form . Hope this helps.
> > >
> > > dn: uid=user4F, ou=People, dc=example, dc=com
> > > uid: user4F
> > > cn: User 4F
> > > sn:
> > > givenName:
> > > ou: People
> > > objectClass: top
> > > objectClass: person
> > > objectClass: organizationalPerson
> > > objectClass: inetOrgPerson
> > > description: This is user4F's description
> > > mail:
> > > use...@test.com
> > >
> > > userPassword: user4F
> > > userCertificate;binary::
> > > MIID5zCCA1CgAwIBAgIDAIF5MA0GCSqGSIb3DQEBBQUAMF4xCzAJ
> > >
> > > BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UE
> > >
> > > CxMDUEtJMRkwFwYDVQQDExBET0QgQ0xBU1MgMyBDQS0zMB4XDTAxMTExNDAwMDAwMFoXDTA0MTEx
> > >
> > > MzAwMDAwMFowdTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE
> > >
> > > CxMDRG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA1VTTjEiMCAGA1UEAxMZU0xBQ0suU1RBQ0VZ
> > >
> > > LkouMTAzNTQ3MjE4MTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnma4IZobULRwrDto4O/U
> > >
> > > mXXVtW1MDuYhooo7/5H6O+9WVWIHMKNW+TvonliezYE/N3VwHG8IFJrnjzHjtrmD/iYi+kl3jz5U
> > >
> > > QmaS/F1fDiP2/G9hEhc5QP6ZCpjWUjf/0m0NjwFiAxLGWNQV9oBqhWU+fwBxD4gGMWRwzGrbVK8C
> > >
> > > AwEAAaOCAZowggGWMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBQH4UHGgQthSDSPSnwyinB7
> > >
> > > UgD4MzAdBgNVHQ4EFgQUa6cO9LyOgFuZhaw2S+CKYh8W6NIwFgYDVR0gBA8wDTALBglghkgBZQIB
> > >
> > > CwkwfgYDVR0SBHcwdYZzbGRhcDovL2RzLTMuYzNwa2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0Ql
> > >
> > > MjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292
> > >
> > > ZXJubWVudCUyY2MlM2RVUzCBqwYDVR0fBIGjMIGgMIGdoIGaoIGXhoGUbGRhcDovL2RzLTMuYzNw
> > >
> > > a2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0kl
> > >
> > > MmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJl
> > >
> > > dm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOBgQB5aLv3JjaAb+eIOrW3niXs96na
> > >
> > > mbjDq1IbWK55YVcpCBgD2fYasSlEmnt7ykQlYW8woRORaKv9ERpTcfcg4odi9VbtzIyzYHVyY5DU
> > > LuaEhqNiKCnjqWXPeMHmtD2H6nBiDAo6tfyitL5E+NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==
> > >
> > >
> > >
> > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> > > "ou=people, dc=example, dc=com" "(usercertificate;binary=*)"
> > >
> > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> > > "ou=people, dc=example, dc=com" "(usercertificate=*)"
> > >
> > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> > > "ou=people, dc=example, dc=com"
> > >
[389-devel] Re: How to create a user with certificate with lib389
Main aim of the test case is filter user with binary search not the base64
.
(Pdb) six.ensure_str(crt)
*** UnicodeDecodeError: 'utf-8' codec can't decode byte 0x82 in position 1:
invalid start byte
On Thu, Jun 13, 2019 at 7:05 PM William Brown wrote:
> I'm really suspicious here that your escape bytes is not needed for ldap
> as much as to prevent python state leaking into the string and the data.
> I'm wondering if there is a better approach
>
> Can ldap filters take base64 instead? Perhaps the issue with your filter
> atm is that you are putting a byte string into an f string so that formats
> with escapes. Have you tried ensure_str() instead?
>
>
>
> > On 13 Jun 2019, at 15:29, Anuj Borah wrote:
> >
> > Yes, it is. but with escape_bytes function only.
> >
> > (Pdb) Accounts(standalone,
> DEFAULT_SUFFIX).filter(f"(userCertificate={crt})")
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
> 'No such file or directory'}
> >
> > And finally .
> > Accounts(standalone,
> DEFAULT_SUFFIX).filter(f"(userCertificate={escape_bytes(crt)})") >>>
> escape_bytes(this is function i want to put in utils.py)
> > []
> >
> >
> >
> > On Thu, Jun 13, 2019 at 6:56 PM William Brown wrote:
> > Is the test case *just* testing if binary searching of attributes works?
> >
> > > On 13 Jun 2019, at 15:25, Anuj Borah wrote:
> > >
> > > @William Brown
> > >
> > >
> > > This is my test case in bash form . Hope this helps.
> > >
> > > dn: uid=user4F, ou=People, dc=example, dc=com
> > > uid: user4F
> > > cn: User 4F
> > > sn:
> > > givenName:
> > > ou: People
> > > objectClass: top
> > > objectClass: person
> > > objectClass: organizationalPerson
> > > objectClass: inetOrgPerson
> > > description: This is user4F's description
> > > mail:
> > > use...@test.com
> > >
> > > userPassword: user4F
> > > userCertificate;binary::
> MIID5zCCA1CgAwIBAgIDAIF5MA0GCSqGSIb3DQEBBQUAMF4xCzAJ
> > >
> BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UE
> > >
> CxMDUEtJMRkwFwYDVQQDExBET0QgQ0xBU1MgMyBDQS0zMB4XDTAxMTExNDAwMDAwMFoXDTA0MTEx
> > >
> MzAwMDAwMFowdTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE
> > >
> CxMDRG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA1VTTjEiMCAGA1UEAxMZU0xBQ0suU1RBQ0VZ
> > >
> LkouMTAzNTQ3MjE4MTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnma4IZobULRwrDto4O/U
> > >
> mXXVtW1MDuYhooo7/5H6O+9WVWIHMKNW+TvonliezYE/N3VwHG8IFJrnjzHjtrmD/iYi+kl3jz5U
> > >
> QmaS/F1fDiP2/G9hEhc5QP6ZCpjWUjf/0m0NjwFiAxLGWNQV9oBqhWU+fwBxD4gGMWRwzGrbVK8C
> > >
> AwEAAaOCAZowggGWMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBQH4UHGgQthSDSPSnwyinB7
> > >
> UgD4MzAdBgNVHQ4EFgQUa6cO9LyOgFuZhaw2S+CKYh8W6NIwFgYDVR0gBA8wDTALBglghkgBZQIB
> > >
> CwkwfgYDVR0SBHcwdYZzbGRhcDovL2RzLTMuYzNwa2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0Ql
> > >
> MjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292
> > >
> ZXJubWVudCUyY2MlM2RVUzCBqwYDVR0fBIGjMIGgMIGdoIGaoIGXhoGUbGRhcDovL2RzLTMuYzNw
> > >
> a2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0kl
> > >
> MmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJl
> > >
> dm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOBgQB5aLv3JjaAb+eIOrW3niXs96na
> > >
> mbjDq1IbWK55YVcpCBgD2fYasSlEmnt7ykQlYW8woRORaKv9ERpTcfcg4odi9VbtzIyzYHVyY5DU
> > >
> LuaEhqNiKCnjqWXPeMHmtD2H6nBiDAo6tfyitL5E+NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==
> > >
> > >
> > >
> > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com" "(usercertificate;binary=*)"
> > >
> > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com" "(usercertificate=*)"
> > >
> > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com"
>
[389-devel] Please review: revert path change for python
https://pagure.io/389-ds-base/pull-request/50444 — 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: How to create a user with certificate with lib389
I'm really suspicious here that your escape bytes is not needed for ldap as
much as to prevent python state leaking into the string and the data. I'm
wondering if there is a better approach
Can ldap filters take base64 instead? Perhaps the issue with your filter atm is
that you are putting a byte string into an f string so that formats with
escapes. Have you tried ensure_str() instead?
> On 13 Jun 2019, at 15:29, Anuj Borah wrote:
>
> Yes, it is. but with escape_bytes function only.
>
> (Pdb) Accounts(standalone, DEFAULT_SUFFIX).filter(f"(userCertificate={crt})")
> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 'No
> such file or directory'}
>
> And finally .
> Accounts(standalone,
> DEFAULT_SUFFIX).filter(f"(userCertificate={escape_bytes(crt)})") >>>
> escape_bytes(this is function i want to put in utils.py)
> []
>
>
>
> On Thu, Jun 13, 2019 at 6:56 PM William Brown wrote:
> Is the test case *just* testing if binary searching of attributes works?
>
> > On 13 Jun 2019, at 15:25, Anuj Borah wrote:
> >
> > @William Brown
> >
> >
> > This is my test case in bash form . Hope this helps.
> >
> > dn: uid=user4F, ou=People, dc=example, dc=com
> > uid: user4F
> > cn: User 4F
> > sn:
> > givenName:
> > ou: People
> > objectClass: top
> > objectClass: person
> > objectClass: organizationalPerson
> > objectClass: inetOrgPerson
> > description: This is user4F's description
> > mail:
> > use...@test.com
> >
> > userPassword: user4F
> > userCertificate;binary::
> > MIID5zCCA1CgAwIBAgIDAIF5MA0GCSqGSIb3DQEBBQUAMF4xCzAJ
> >
> > BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UE
> >
> > CxMDUEtJMRkwFwYDVQQDExBET0QgQ0xBU1MgMyBDQS0zMB4XDTAxMTExNDAwMDAwMFoXDTA0MTEx
> >
> > MzAwMDAwMFowdTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE
> >
> > CxMDRG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA1VTTjEiMCAGA1UEAxMZU0xBQ0suU1RBQ0VZ
> >
> > LkouMTAzNTQ3MjE4MTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnma4IZobULRwrDto4O/U
> >
> > mXXVtW1MDuYhooo7/5H6O+9WVWIHMKNW+TvonliezYE/N3VwHG8IFJrnjzHjtrmD/iYi+kl3jz5U
> >
> > QmaS/F1fDiP2/G9hEhc5QP6ZCpjWUjf/0m0NjwFiAxLGWNQV9oBqhWU+fwBxD4gGMWRwzGrbVK8C
> >
> > AwEAAaOCAZowggGWMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBQH4UHGgQthSDSPSnwyinB7
> >
> > UgD4MzAdBgNVHQ4EFgQUa6cO9LyOgFuZhaw2S+CKYh8W6NIwFgYDVR0gBA8wDTALBglghkgBZQIB
> >
> > CwkwfgYDVR0SBHcwdYZzbGRhcDovL2RzLTMuYzNwa2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0Ql
> >
> > MjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292
> >
> > ZXJubWVudCUyY2MlM2RVUzCBqwYDVR0fBIGjMIGgMIGdoIGaoIGXhoGUbGRhcDovL2RzLTMuYzNw
> >
> > a2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0kl
> >
> > MmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJl
> >
> > dm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOBgQB5aLv3JjaAb+eIOrW3niXs96na
> >
> > mbjDq1IbWK55YVcpCBgD2fYasSlEmnt7ykQlYW8woRORaKv9ERpTcfcg4odi9VbtzIyzYHVyY5DU
> > LuaEhqNiKCnjqWXPeMHmtD2H6nBiDAo6tfyitL5E+NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==
> >
> >
> >
> > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b "ou=people,
> > dc=example, dc=com" "(usercertificate;binary=*)"
> >
> > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b "ou=people,
> > dc=example, dc=com" "(usercertificate=*)"
> >
> > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b "ou=people,
> > dc=example, dc=com"
> >
[389-devel] Re: How to create a user with certificate with lib389
Yes, it is. but with escape_bytes function only.
(Pdb) Accounts(standalone,
DEFAULT_SUFFIX).filter(f"(userCertificate={crt})")
*** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
'No such file or directory'}
And finally .
Accounts(standalone,
DEFAULT_SUFFIX).filter(f"(userCertificate={escape_bytes(crt)})") >>>
escape_bytes(this is function i want to put in utils.py)
[]
On Thu, Jun 13, 2019 at 6:56 PM William Brown wrote:
> Is the test case *just* testing if binary searching of attributes works?
>
> > On 13 Jun 2019, at 15:25, Anuj Borah wrote:
> >
> > @William Brown
> >
> >
> > This is my test case in bash form . Hope this helps.
> >
> > dn: uid=user4F, ou=People, dc=example, dc=com
> > uid: user4F
> > cn: User 4F
> > sn:
> > givenName:
> > ou: People
> > objectClass: top
> > objectClass: person
> > objectClass: organizationalPerson
> > objectClass: inetOrgPerson
> > description: This is user4F's description
> > mail:
> > use...@test.com
> >
> > userPassword: user4F
> > userCertificate;binary::
> MIID5zCCA1CgAwIBAgIDAIF5MA0GCSqGSIb3DQEBBQUAMF4xCzAJ
> >
> BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UE
> >
> CxMDUEtJMRkwFwYDVQQDExBET0QgQ0xBU1MgMyBDQS0zMB4XDTAxMTExNDAwMDAwMFoXDTA0MTEx
> >
> MzAwMDAwMFowdTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE
> >
> CxMDRG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA1VTTjEiMCAGA1UEAxMZU0xBQ0suU1RBQ0VZ
> >
> LkouMTAzNTQ3MjE4MTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnma4IZobULRwrDto4O/U
> >
> mXXVtW1MDuYhooo7/5H6O+9WVWIHMKNW+TvonliezYE/N3VwHG8IFJrnjzHjtrmD/iYi+kl3jz5U
> >
> QmaS/F1fDiP2/G9hEhc5QP6ZCpjWUjf/0m0NjwFiAxLGWNQV9oBqhWU+fwBxD4gGMWRwzGrbVK8C
> >
> AwEAAaOCAZowggGWMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBQH4UHGgQthSDSPSnwyinB7
> >
> UgD4MzAdBgNVHQ4EFgQUa6cO9LyOgFuZhaw2S+CKYh8W6NIwFgYDVR0gBA8wDTALBglghkgBZQIB
> >
> CwkwfgYDVR0SBHcwdYZzbGRhcDovL2RzLTMuYzNwa2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0Ql
> >
> MjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292
> >
> ZXJubWVudCUyY2MlM2RVUzCBqwYDVR0fBIGjMIGgMIGdoIGaoIGXhoGUbGRhcDovL2RzLTMuYzNw
> >
> a2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0kl
> >
> MmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJl
> >
> dm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOBgQB5aLv3JjaAb+eIOrW3niXs96na
> >
> mbjDq1IbWK55YVcpCBgD2fYasSlEmnt7ykQlYW8woRORaKv9ERpTcfcg4odi9VbtzIyzYHVyY5DU
> > LuaEhqNiKCnjqWXPeMHmtD2H6nBiDAo6tfyitL5E+NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==
> >
> >
> >
> > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com" "(usercertificate;binary=*)"
> >
> > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com" "(usercertificate=*)"
> >
> > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com"
>
[389-devel] Re: How to create a user with certificate with lib389
Is the test case *just* testing if binary searching of attributes works? > On 13 Jun 2019, at 15:25, Anuj Borah wrote: > > @William Brown > > > This is my test case in bash form . Hope this helps. > > dn: uid=user4F, ou=People, dc=example, dc=com > uid: user4F > cn: User 4F > sn: > givenName: > ou: People > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > description: This is user4F's description > mail: > use...@test.com > > userPassword: user4F > userCertificate;binary:: MIID5zCCA1CgAwIBAgIDAIF5MA0GCSqGSIb3DQEBBQUAMF4xCzAJ > BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UE > CxMDUEtJMRkwFwYDVQQDExBET0QgQ0xBU1MgMyBDQS0zMB4XDTAxMTExNDAwMDAwMFoXDTA0MTEx > MzAwMDAwMFowdTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE > CxMDRG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA1VTTjEiMCAGA1UEAxMZU0xBQ0suU1RBQ0VZ > LkouMTAzNTQ3MjE4MTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnma4IZobULRwrDto4O/U > mXXVtW1MDuYhooo7/5H6O+9WVWIHMKNW+TvonliezYE/N3VwHG8IFJrnjzHjtrmD/iYi+kl3jz5U > QmaS/F1fDiP2/G9hEhc5QP6ZCpjWUjf/0m0NjwFiAxLGWNQV9oBqhWU+fwBxD4gGMWRwzGrbVK8C > AwEAAaOCAZowggGWMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBQH4UHGgQthSDSPSnwyinB7 > UgD4MzAdBgNVHQ4EFgQUa6cO9LyOgFuZhaw2S+CKYh8W6NIwFgYDVR0gBA8wDTALBglghkgBZQIB > CwkwfgYDVR0SBHcwdYZzbGRhcDovL2RzLTMuYzNwa2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0Ql > MjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292 > ZXJubWVudCUyY2MlM2RVUzCBqwYDVR0fBIGjMIGgMIGdoIGaoIGXhoGUbGRhcDovL2RzLTMuYzNw > a2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0kl > MmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJl > dm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOBgQB5aLv3JjaAb+eIOrW3niXs96na > mbjDq1IbWK55YVcpCBgD2fYasSlEmnt7ykQlYW8woRORaKv9ERpTcfcg4odi9VbtzIyzYHVyY5DU > LuaEhqNiKCnjqWXPeMHmtD2H6nBiDAo6tfyitL5E+NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw== > > > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b "ou=people, > dc=example, dc=com" "(usercertificate;binary=*)" > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b "ou=people, > dc=example, dc=com" "(usercertificate=*)" > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b "ou=people, > dc=example, dc=com" >
[389-devel] Re: How to create a user with certificate with lib389
@William Brown This is my test case in bash form . Hope this helps. dn: uid=user4F, ou=People, dc=example, dc=com uid: user4F cn: User 4F sn: givenName: ou: People objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson description: This is user4F's description mail: use...@test.com userPassword: user4F userCertificate;binary:: MIID5zCCA1CgAwIBAgIDAIF5MA0GCSqGSIb3DQEBBQUAMF4xCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UE CxMDUEtJMRkwFwYDVQQDExBET0QgQ0xBU1MgMyBDQS0zMB4XDTAxMTExNDAwMDAwMFoXDTA0MTEx MzAwMDAwMFowdTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE CxMDRG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA1VTTjEiMCAGA1UEAxMZU0xBQ0suU1RBQ0VZ LkouMTAzNTQ3MjE4MTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnma4IZobULRwrDto4O/U mXXVtW1MDuYhooo7/5H6O+9WVWIHMKNW+TvonliezYE/N3VwHG8IFJrnjzHjtrmD/iYi+kl3jz5U QmaS/F1fDiP2/G9hEhc5QP6ZCpjWUjf/0m0NjwFiAxLGWNQV9oBqhWU+fwBxD4gGMWRwzGrbVK8C AwEAAaOCAZowggGWMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBQH4UHGgQthSDSPSnwyinB7 UgD4MzAdBgNVHQ4EFgQUa6cO9LyOgFuZhaw2S+CKYh8W6NIwFgYDVR0gBA8wDTALBglghkgBZQIB CwkwfgYDVR0SBHcwdYZzbGRhcDovL2RzLTMuYzNwa2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0Ql MjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292 ZXJubWVudCUyY2MlM2RVUzCBqwYDVR0fBIGjMIGgMIGdoIGaoIGXhoGUbGRhcDovL2RzLTMuYzNw a2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0kl MmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJl dm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOBgQB5aLv3JjaAb+eIOrW3niXs96na mbjDq1IbWK55YVcpCBgD2fYasSlEmnt7ykQlYW8woRORaKv9ERpTcfcg4odi9VbtzIyzYHVyY5DU LuaEhqNiKCnjqWXPeMHmtD2H6nBiDAo6tfyitL5E+NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw== #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b "ou=people, dc=example, dc=com" "(usercertificate;binary=*)" #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b "ou=people, dc=example, dc=com" "(usercertificate=*)" #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b "ou=people, dc=example, dc=com"
[389-devel] Re: How to create a user with certificate with lib389
I'm sorry, you didn't answer my questions can you answer the below
questions, exactly and precisely, else I can't help you :(
>
> * WHAT is the test you are creating? What does it test? How? What steps from
> start to finish? Please list this exactly.
> * Use SSCA to make the user cert - it creates pem and der copies
> * Have you looked at:
> https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/idm/account.py#_103
>
> Till this point all ok . But not ok . Its giving error .
> (Pdb) Account(standalone,
> 'uid=testuser,ou=People,dc=example,dc=com').enroll_certificate(tls_locs['crt_der_path'])
> *** NameError: name 'ds_is_older' is not defined
>
> Or
>
> (Pdb) users.list()[0].enroll_certificate(tls_locs['crt_der_path'])
> *** NameError: name 'ds_is_older' is not defined
>
> Is there a problem with account.py file .
>
> https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/idm/account.py
> It did not import from lib389.utils import (ds_is_older)
>
>
> Any way after using SSCA we have got the user with userCertificate field .
>
> (Pdb) Account(standalone,
> 'uid=testuser,ou=People,dc=example,dc=com')._unsafe_raw_entry()
> dn: uid=testuser,ou=People,dc=example,dc=com
> cn: testuser
> gidNumber: 2000
> homeDirectory: /home/testuser
> objectClass: top
> objectClass: account
> objectClass: posixaccount
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: nsMemberOf
> objectClass: nsAccount
> objectClass: person
> sn: user
> uid: testuser
> uidNumber: 1000
> userCertificate;binary::
> MIIFcjCCA1qgAwIBAgIFALFmh3wwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCQVUxEzARBgNVBAgTClF1ZWVuc2xhbmQxDjAMBgNVBAcTBTM4OWRzMRAwDgYDVQQKEwd0ZXN0aW5nMR8wHQYDVQQDExZzc2NhLjM4OWRzLmV4YW1wbGUuY29tMB4XDTE5MDYxMzEzMDkwM1oXDTIxMDYxMzEzMDkwM1owVzELMAkGA1UEBhMCQVUxEzARBgNVBAgTClF1ZWVuc2xhbmQxDjAMBgNVBAcTBTM4OWRzMRAwDgYDVQQKEwd0ZXN0aW5nMREwDwYDVQQDEwh0ZXN0dXNlcjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALUUafcfMOhoY+8C3L/IYPlaxex2BcYqbTbD+FWonRlp4pE1CdZbk/2jdzkndBVMl4iTF2L0+y3SyNOsG8Lonbdhxz5bxwhzhDpTBD3wLbFlF5r9fe5VR7KfbhvLUSPpfra+UfhiFzgRPkyItUi6KFvcc9Zt2toXBydRaef0yjwI2yv/ileelrCeFKDtUNPAjXnHnqXH/aqpm3cYYy0KWqxSeKe4ET8ymkffJs2Tsomd7ofgcwWtce5bdMxtbhc2sRIbbbdQRIf0mXromkXftAXjTZb9gUAsNESfuRwulY1vkyY5LRhUvDuufxMrEnooJ5t7a6oOsGGrsyQddOWJMPEakuJbMpC/IonMkJdF6oNnfWdruFqBcfP1pBxjiNz1ZFbE/XudBEEuHHRh8wrR5uljH3Y+AUTUUuhVm7Yiuo23B041C1lggVNXpeCxkcYwJDEvJfTzXKOrgL0Pk36u4FhnsXFfzcWJuiOSNdeiBtSOc68g3YmMZyfjCAXPk77TEqrm8KdwBKLg90nnyjEjYqquMMIPzCJVoyH0ckmzA/W8ClQ4VEHav6wmcLjH3tE6eJofl9cLTUL
>
> 6Yfuxijf6AFGkcAfhXtblLiB3jeKiqjC91gqWh+bbXRFIEx50LoColCo55mUAmbse4z/RNSFfCG6JViWDrRiTy8LiDgGfDj2tAgMBAAGjNzA1MBEGCWCGSAGG+EIBAQQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8EBAMCBPAwDQYJKoZIhvcNAQELBQADggIBAEpq9ZWRdpXTFzYtY++vbZZyQ+EDAyIj34jKzmCsXvnT6LIfu6K1dYZl83bhLKriurFmQijZb98JVCT+i7LpICb6lVcNU9Jz9CtWf9cWTvpqXPlHRgS+qxGH96vIQ4PDPzcI7HhhPlz7THtuPY1jFdF/vY8nbNdWRrWymrCYxk27c7a1g5crixPwggs1Kv3Oy045Xyv5c9KfA511IEC/DGWwUyOVx6l7gYQXVTnWGqwF+JfLoZvWlqPdkoH7N3dHPdmZQsG9ZEghjslE2SbaUp2XpvyhU6XYa8q9NFMCnm2E07Jm7R/Spah/gl0YiscG6FMtI3EISagQb5vxIJT9UjnYfj9y7Mu/U31wQEos9plJHxMtFZBjbumrFxziCIhNLzTgzX77CnBwIdA69fU5YyRJLLge2uO6zJBbAHKyz+FGbz+lA+oLFMSYPA1McRagRpe5FdhFoajrwSe6NIErhyMfhgGLHr7OQTznRlkqafamsbnxa2f4HzVlMAw1j5CD4uCeJHKpAvRMb1BUYxXyyYrw8W0uFa5yuIa0TzK12gz6/AgxXKOAsH/WHGd9ial4hG9c746D/KMyqERszb0bRRs4ncMnJtXFov41/jd1btm6+Vs9FpnQKPJ27zMbG2S63NQ1V++M6EbggR7cQbFBErzsOt1Jp3sIssuE06hpsteB
>
>
> Now i want to filter that user with filter.
>
> (Pdb) crt = open('/etc/dirsrv/slapd-standalone1/user-testuser.der',
> 'rb').read()
> (Pdb) crt
>
[Bug 1720241] New: perl-Test-Strict-0.49 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1720241 Bug ID: 1720241 Summary: perl-Test-Strict-0.49 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Strict Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.49 Current version/release in rawhide: 0.48-2.fc31 URL: http://search.cpan.org/dist/Test-Strict/ 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/3419/ -- 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] Re: How to create a user with certificate with lib389
On Thu, Jun 13, 2019 at 6:05 PM William Brown wrote:
>
>
> > On 13 Jun 2019, at 14:27, Anuj Borah wrote:
> >
> >
>
> Okay, so:
>
> * WHAT is the test you are creating? What does it test? How? What steps
> from start to finish? Please list this exactly.
> * Use SSCA to make the user cert - it creates pem and der copies
> * Have you looked at:
> https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/idm/account.py#_103
Till this point all ok . But not ok . Its giving error .
(Pdb) Account(standalone,
'uid=testuser,ou=People,dc=example,dc=com').enroll_certificate(tls_locs['crt_der_path'])
*** NameError: name 'ds_is_older' is not defined
Or
(Pdb) users.list()[0].enroll_certificate(tls_locs['crt_der_path'])
*** NameError: name 'ds_is_older' is not defined
Is there a problem with account.py file .
https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/idm/account.py
It did not import from lib389.utils import (ds_is_older)
Any way after using SSCA we have got the user with userCertificate field .
(Pdb) Account(standalone,
'uid=testuser,ou=People,dc=example,dc=com')._unsafe_raw_entry()
dn: uid=testuser,ou=People,dc=example,dc=com
cn: testuser
gidNumber: 2000
homeDirectory: /home/testuser
objectClass: top
objectClass: account
objectClass: posixaccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: nsMemberOf
objectClass: nsAccount
objectClass: person
sn: user
uid: testuser
uidNumber: 1000
userCertificate;binary::
MIIFcjCCA1qgAwIBAgIFALFmh3wwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCQVUxEzARBgNVBAgTClF1ZWVuc2xhbmQxDjAMBgNVBAcTBTM4OWRzMRAwDgYDVQQKEwd0ZXN0aW5nMR8wHQYDVQQDExZzc2NhLjM4OWRzLmV4YW1wbGUuY29tMB4XDTE5MDYxMzEzMDkwM1oXDTIxMDYxMzEzMDkwM1owVzELMAkGA1UEBhMCQVUxEzARBgNVBAgTClF1ZWVuc2xhbmQxDjAMBgNVBAcTBTM4OWRzMRAwDgYDVQQKEwd0ZXN0aW5nMREwDwYDVQQDEwh0ZXN0dXNlcjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALUUafcfMOhoY+8C3L/IYPlaxex2BcYqbTbD+FWonRlp4pE1CdZbk/2jdzkndBVMl4iTF2L0+y3SyNOsG8Lonbdhxz5bxwhzhDpTBD3wLbFlF5r9fe5VR7KfbhvLUSPpfra+UfhiFzgRPkyItUi6KFvcc9Zt2toXBydRaef0yjwI2yv/ileelrCeFKDtUNPAjXnHnqXH/aqpm3cYYy0KWqxSeKe4ET8ymkffJs2Tsomd7ofgcwWtce5bdMxtbhc2sRIbbbdQRIf0mXromkXftAXjTZb9gUAsNESfuRwulY1vkyY5LRhUvDuufxMrEnooJ5t7a6oOsGGrsyQddOWJMPEakuJbMpC/IonMkJdF6oNnfWdruFqBcfP1pBxjiNz1ZFbE/XudBEEuHHRh8wrR5uljH3Y+AUTUUuhVm7Yiuo23B041C1lggVNXpeCxkcYwJDEvJfTzXKOrgL0Pk36u4FhnsXFfzcWJuiOSNdeiBtSOc68g3YmMZyfjCAXPk77TEqrm8KdwBKLg90nnyjEjYqquMMIPzCJVoyH0ckmzA/W8ClQ4VEHav6wmcLjH3tE6eJofl9cLTUL
6Yfuxijf6AFGkcAfhXtblLiB3jeKiqjC91gqWh+bbXRFIEx50LoColCo55mUAmbse4z/RNSFfCG6JViWDrRiTy8LiDgGfDj2tAgMBAAGjNzA1MBEGCWCGSAGG+EIBAQQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8EBAMCBPAwDQYJKoZIhvcNAQELBQADggIBAEpq9ZWRdpXTFzYtY++vbZZyQ+EDAyIj34jKzmCsXvnT6LIfu6K1dYZl83bhLKriurFmQijZb98JVCT+i7LpICb6lVcNU9Jz9CtWf9cWTvpqXPlHRgS+qxGH96vIQ4PDPzcI7HhhPlz7THtuPY1jFdF/vY8nbNdWRrWymrCYxk27c7a1g5crixPwggs1Kv3Oy045Xyv5c9KfA511IEC/DGWwUyOVx6l7gYQXVTnWGqwF+JfLoZvWlqPdkoH7N3dHPdmZQsG9ZEghjslE2SbaUp2XpvyhU6XYa8q9NFMCnm2E07Jm7R/Spah/gl0YiscG6FMtI3EISagQb5vxIJT9UjnYfj9y7Mu/U31wQEos9plJHxMtFZBjbumrFxziCIhNLzTgzX77CnBwIdA69fU5YyRJLLge2uO6zJBbAHKyz+FGbz+lA+oLFMSYPA1McRagRpe5FdhFoajrwSe6NIErhyMfhgGLHr7OQTznRlkqafamsbnxa2f4HzVlMAw1j5CD4uCeJHKpAvRMb1BUYxXyyYrw8W0uFa5yuIa0TzK12gz6/AgxXKOAsH/WHGd9ial4hG9c746D/KMyqERszb0bRRs4ncMnJtXFov41/jd1btm6+Vs9FpnQKPJ27zMbG2S63NQ1V++M6EbggR7cQbFBErzsOt1Jp3sIssuE06hpsteB
Now i want to filter that user with filter.
(Pdb) crt = open('/etc/dirsrv/slapd-standalone1/user-testuser.der',
'rb').read()
(Pdb) crt
[389-devel] Re: How to create a user with certificate with lib389
> On 13 Jun 2019, at 14:27, Anuj Borah wrote: > > Okay, so: * WHAT is the test you are creating? What does it test? How? What steps from start to finish? Please list this exactly. * Use SSCA to make the user cert - it creates pem and der copies * Have you looked at: https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/idm/account.py#_103 * Consider checking: https://pagure.io/389-ds-base/pull-request/49579#request_diff we can likely pull out the python from this branch and commit to master as it adds a lot of TLS support. Thanks — 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: How to create a user with certificate with lib389
@William Brown
Please check the attached test case .
I want to put escape_bytes function to lib389 utils.py file .
Regards
Anuj Borah
On Mon, Jun 10, 2019 at 2:18 PM William Brown wrote:
>
>
> > On 9 Jun 2019, at 03:40, Anuj Borah wrote:
> >
> > @William Brown
> >
> > Yes, it does.
> >
> > Currently i am porting this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=170520
> >
> > I think with help of this script it will be impossible to port it .
>
> I'm not authorised to view that bug. :)
>
> I think youll need to describe, exactly, in sequence the order of events
> you want to test so I can advise properly.
>
> >
> > Do you have any advice .
> >
> > Regards
> > Anuj Borah
> >
> >
> > On Fri, Jun 7, 2019 at 2:47 PM William Brown wrote:
> > I haven't read the link but maybe there is some confusion about TLS
> binding here. You do the create_rsa_user and that only set's up the
> certificates.
> >
> > > On 4 Jun 2019, at 17:51, Anuj Borah wrote:
> > >
> > > @William Brown
> > >
> > > Thanks , I am doing the same . Trying to follow it . (i have make this
> script 99% pass)
> > >
> > > But its way too old . It uses some like :
> > >
> > > standalone.nss_ssl.create_rsa_user('testuser') not valid
> (NssSsl(standalone).create_rsa_user('testuser'))
> > >
> > > standalone.nss_ssl.get_rsa_user('testuser') -- not valid
> (NssSsl(standalone).get_rsa_user('testuser'))
> >
> > IIRC this syntax is valid, but maybe the linking type was removed.
> >
> > >
> > > standalone.openConnection --- I dont know what is it . May be bind.
> >
> > Yes, i think this is bind now. If you grep for create_rsa_user in the
> tests you may find another example.
> >
> > >
> > > And Most importantly, after i have make this script 99% pass . I am
> not able to see the usercertificate field in the test user that was created
> during the test . while i do _unsafe_raw_entry()
> >
> > Because you don't need it. The certificate's cn is mapped to the cn in
> the directory, and then because the certificate was issued be the ca, it
> "confirms" the users identity. No userCertificate attribute required.
> >
> > There is a configuration that DOES require the certificate to not only
> be signed, but also in userCertificate for binary matching, but this is a
> configuration option, not the default. I seem to recall helping document
> all this with Marc, so it should be in the latest RHDS documentation.
> Generally though, the userCertificate attribute today would be used to
> allow a client like SSSD to read the userCertificate to allow smartCard
> authentication to a workstation.
> >
> > Does that help a bit?
> >
> > >
> > > Also mind changing the lib389 doc
> https://spichugi.fedorapeople.org/html/guidelines.html#setting-up-ssl-tls
> . Its the same test case given there , which is not relevant now .
> > >
> > > Regards
> > > Anuj Borah
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Jun 4, 2019 at 9:08 PM William Brown wrote:
> > > I'm currently traveling at the moment, but I can have a look later to
> update this to work on latest lib389 etc.
> > >
> > > You can read it and use it as an example though, even if it doesn't
> pass ...
> > >
> > >
> > >
> > >
> > > > On 4 Jun 2019, at 16:32, Anuj Borah wrote:
> > > >
> > > > @William Brown
> > > >
> > > > This test script does not pass . Its too old .
> > > >
> > > > Regards
> > > > Anuj Borah
> > > >
> > > > On Tue, Jun 4, 2019 at 8:00 PM William Brown wrote:
> > > > Have a look at this test case if you want to do usercertificate
> generation and authentication :)
> > > >
> > > >
> https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/tests/tls_external_test.py
> > > >
> > > > > On 4 Jun 2019, at 14:31, Anuj Borah wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Let say i want to create a user with userCertificate fileld. My
> user will look like bellow.
> > > > >
> > > > > users_people = UserAccounts(topo.standalone, DEFAULT_SUFFIX)
> > > > > users_people.create(properties={
> > > > > 'uid': 'certUser2',
> > > > > 'cn': 'CUser2',
> > > > > 'sn': 'CertificateUser2',
> > > > > 'givenName': 'CU2',
> > > > > 'description': "This is certUser2's description",
> > > > > 'mail': 'certus...@example.com',
> > > > > 'userPassword': PW_DM,
> > > > > 'userCertificate':
> 'some_cert_+++NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==',
> > > > > 'manager': f'uid=certUser2,ou=People,{DEFAULT_SUFFIX}',
> > > > > 'homeDirectory': '/home/' + 'certUser2',
> > > > > 'uidNumber': '1000',
> > > > > 'gidNumber': '2000'
> > > > > })
> > > > >
> > > > > Here i have put userCertificate field manually (which i dont want
> to do). But how can i achieve this without putting userCertificate field
> manually . Like create a user and userCertificate field will be auto field
> with auto generated certificates .
> > > > >
> > > > > Regards
> > > > > Anuj Borah
> > > > >
[389-devel] Environment variables in systemd
Hi there, There have been a few changes to systemd files recently so I wanted to check about how to correctly supply environment variables to the server. For example, KRB5_KTNAME. Are we doing this still by EnvironmentFile? Or by another method? — 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: Heads-up: rpm 4.15 alpha coming to rawhide
On 6/12/19 1:07 PM, Miroslav Suchý wrote: Dne 10. 06. 19 v 13:39 Panu Matilainen napsal(a): More info and details available in the preliminary release notes at https://rpm.org/wiki/Releases/4.15.0 and the change page linked at the start of this message. Where can I read more about this: > Add support for rootless chroot-operations on Linux (experimental) ? There's not a whole lot to write about, it just means that operations which require chroot() now more or less work for regular users by the way of user namespaces. That more-or-less is part of the reason for the experimental status, as due to the way the user namespace switch is hidden inside rpm's chroot() helpers, it can't fork which would be required (AIUI) to properly set up the uid/gid mappings inside the namespace. So while you can now install into a chroot as a regular user, any files not owned by root (or yourself) will fail, so its not as useful as it seems initially: context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [pmatilai︎sopuli ~]$ rpm -Uvh --root ~/testroot mft/f28-bash.mft warning: /mnt/Packages/b/bash-4.4.19-2.fc28.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 9db62fb1: NOKEY Verifying... # [100%] Preparing... # [100%] Updating / installing... 1:fedora-gpg-keys-28-1 # [ 6%] 2:fedora-repos-28-1# [ 13%] 3:fedora-release-28-1 # [ 19%] 4:setup-2.11.3-1.fc28 # [ 25%] 5:filesystem-3.8-2.fc28# [ 31%] error: unpacking of archive failed on file /var/spool/mail: cpio: chown failed - No such file or directory error: filesystem-3.8-2.fc28.x86_64: install failed 6:basesystem-11-5.fc28 # [ 38%] 7:tzdata-2018d-1.fc28 # [ 44%] 8:ncurses-base-6.1-4.20180224.fc28 # [ 50%] 9:pcre2-10.31-4.fc28 # [ 56%] 10:libselinux-2.7-13.fc28 # [ 63%] 11:ncurses-libs-6.1-4.20180224.fc28 # [ 69%] 12:glibc-langpack-en-2.27-8.fc28# [ 75%] 13:glibc-common-2.27-8.fc28 # [ 81%] 14:glibc-2.27-8.fc28# [ 88%] 15:bash-4.4.19-2.fc28 # [ 94%] 16:libsepol-2.7-6.fc28 # [100%] [pmatilai︎sopuli ~]$ rpm -Va --root ~/testroot Unsatisfied dependencies for bash-4.4.19-2.fc28.x86_64: filesystem >= 3 is needed by (installed) bash-4.4.19-2.fc28.x86_64 missing /usr/lib/systemd/system-preset/85-display-manager.preset .M... g /usr/lib/variant [pmatilai︎sopuli ~]$ It remains to be seen if there's something that we can do to make this work, or whether it's just too much of a hack to live. - Panu - ___ 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] Extra schema from SUSE 12/openldap
Hi all, During my packaging work I have noticed that suse is shipping extra schema for compatability with openldap and some legacy applications. I have attached the tar.gz to check. What would we think about shipping this in the upstream to help ensure compatibility between RH/SUSE/Others in migrations from OpenLDAP -> 389, and between 389 on distros? I think it may also be worth our time to investigate an openldap -> 389 conversion tool, because both RH and SUSE are dropping OpenLDAP so we should help support our users to make the migration as seemless as possible. Thoughts? extra-schema.tgz Description: Binary data — 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: Any new restriction in Koji added recently in Rawhide?
Hello! чт, 13 июн. 2019 г. в 12:49, Petr Pisar : > > On 2019-06-13, Peter Lemenkov wrote: > > I've noticed that I cannot build Elixir in Rawhide anymore. It got > > stuck at tests and all I've got is a cryptic (at least to me) message: > > > > > > + RPM_EC=0 > > BUILDSTDERR: ++ jobs -p > > + exit 0 > > > F31 has a new rpm-build with a new features. Your issue seems like > another bug in the same process clean-up code I reported an hour ago. > See bug #1720143. Yes, looks exactly like my case. Thanks for the pointing out! -- With best regards, Peter Lemenkov. ___ 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: Any new restriction in Koji added recently in Rawhide?
On 6/13/19 12:54 PM, Miroslav Suchý wrote:
Dne 13. 06. 19 v 11:43 Peter Lemenkov napsal(a):
Hello All!
I've noticed that I cannot build Elixir in Rawhide anymore. It got
stuck at tests and all I've got is a cryptic (at least to me) message:
+ RPM_EC=0
BUILDSTDERR: ++ jobs -p
+ exit 0
See this link for full build log:
* https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
* https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
For comparison here is how successful build log for F-30 looks like
(the same package)
* https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
* https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
Are there any differences between Koji settings for Rawhide and F-30
which we should know about? Selinux, resource constraints etc?
This is wrong (not sure if the culprit)
%endif %{__with_rebar3}
I would rewrite it to:
%endif # __with_rebar3
Actually both are wrong, and rpm >= 4.15 will complain (unlike old
versions). Rpm only supports comments at beginning of line, and this
only ever worked by accident.
And definitely rawhide has new rpm (see the announced change) and therefore
rpmbuild.
There should not be any change which can cause this, but regression is always
possible.
If the cause of failure is the same as
https://bugzilla.redhat.com/show_bug.cgi?id=1720143 then it should be
fixed now as of rpm-4.14.90-0.git14653.14.fc31.
If not, feel free to file a new bug to have it investigated. There's
more than two years worth of new code in the new rpm so there's always a
possibility of regressions. Our built-in test-suite cannot even begin to
compete with rawhide in that :)
- Panu -
___
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 1720143] perl-Redis-1.991-10.fc31FTBFS: line 45: kill: (20250) - No such process
https://bugzilla.redhat.com/show_bug.cgi?id=1720143 Panu Matilainen changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||rpm-4.14.90-0.git14653.14.f ||c31 Resolution|--- |RAWHIDE Last Closed||2019-06-13 10:18:19 --- Comment #2 from Panu Matilainen --- Should be fixed in rpm-4.14.90-0.git14653.14.fc31 now. Thanks for the report! -- 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: Any new restriction in Koji added recently in Rawhide?
On 2019-06-13, Peter Lemenkov wrote: > I've noticed that I cannot build Elixir in Rawhide anymore. It got > stuck at tests and all I've got is a cryptic (at least to me) message: > > > + RPM_EC=0 > BUILDSTDERR: ++ jobs -p > + exit 0 > F31 has a new rpm-build with a new features. Your issue seems like another bug in the same process clean-up code I reported an hour ago. See bug #1720143. -- Petr ___ 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: Any new restriction in Koji added recently in Rawhide?
You may consider adding your package to the Koschei service: https://apps.fedoraproject.org/koschei/package/python-elixir which will do rebuilds when the buildroot change, and it will show you the changes in a well readable way. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jun 13, 2019 at 11:44 AM Peter Lemenkov wrote: > > Hello All! > I've noticed that I cannot build Elixir in Rawhide anymore. It got > stuck at tests and all I've got is a cryptic (at least to me) message: > > > + RPM_EC=0 > BUILDSTDERR: ++ jobs -p > + exit 0 > > > See this link for full build log: > > * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975 > > For comparison here is how successful build log for F-30 looks like > (the same package) > > * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984 > > Are there any differences between Koji settings for Rawhide and F-30 > which we should know about? Selinux, resource constraints etc? > -- > With best regards, Peter Lemenkov. > ___ > 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: Any new restriction in Koji added recently in Rawhide?
Dne 13. 06. 19 v 11:43 Peter Lemenkov napsal(a):
> Hello All!
> I've noticed that I cannot build Elixir in Rawhide anymore. It got
> stuck at tests and all I've got is a cryptic (at least to me) message:
>
>
> + RPM_EC=0
> BUILDSTDERR: ++ jobs -p
> + exit 0
>
>
> See this link for full build log:
>
> * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
>
> For comparison here is how successful build log for F-30 looks like
> (the same package)
>
> * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
>
> Are there any differences between Koji settings for Rawhide and F-30
> which we should know about? Selinux, resource constraints etc?
>
This is wrong (not sure if the culprit)
%endif %{__with_rebar3}
I would rewrite it to:
%endif # __with_rebar3
And definitely rawhide has new rpm (see the announced change) and therefore
rpmbuild.
There should not be any change which can cause this, but regression is always
possible.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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
Any new restriction in Koji added recently in Rawhide?
Hello All! I've noticed that I cannot build Elixir in Rawhide anymore. It got stuck at tests and all I've got is a cryptic (at least to me) message: + RPM_EC=0 BUILDSTDERR: ++ jobs -p + exit 0 See this link for full build log: * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975 For comparison here is how successful build log for F-30 looks like (the same package) * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984 Are there any differences between Koji settings for Rawhide and F-30 which we should know about? Selinux, resource constraints etc? -- With best regards, Peter Lemenkov. ___ 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 1720143] perl-Redis-1.991-10.fc31FTBFS: line 45: kill: (20250) - No such process
https://bugzilla.redhat.com/show_bug.cgi?id=1720143 Panu Matilainen changed: What|Removed |Added CC||i.gnatenko.br...@gmail.com, ||m...@fedoraproject.org, ||pmati...@redhat.com, ||pmora...@redhat.com, ||vmukh...@redhat.com Component|perl-Redis |rpm Assignee|dd...@cpan.org |packaging-team-maint@redhat ||.com --- Comment #1 from Panu Matilainen --- This is an rpm bug, it shouldn't error out because a process we were about to kill died on its own. If you want to wait on the pid, you're of course free to do so anyway. -- 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 1720143] New: perl-Redis-1.991-10.fc31FTBFS: line 45: kill: (20250) - No such process
https://bugzilla.redhat.com/show_bug.cgi?id=1720143 Bug ID: 1720143 Summary: perl-Redis-1.991-10.fc31FTBFS: line 45: kill: (20250) - No such process Product: Fedora Version: rawhide URL: https://apps.fedoraproject.org/koschei/build/6561705 Status: NEW Component: perl-Redis Assignee: dd...@cpan.org Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: dd...@cpan.org, packaging-team-ma...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora perl-Redis-1.991-10.fc31 fails to build in F31: + make test + redis-server - BUILDSTDERR: # child is ready to test, signal parent to kill our server BUILDSTDERR: # parent killed pub/sub redis server, signal child to proceed BUILDSTDERR: # now, check wait_for_messages(), should die... BUILDSTDERR: # parent waiting for child 20292... BUILDSTDERR: # CHILD: reconnected (with a 10s timeout) BUILDSTDERR: # CHILD: is ready to test, signal parent to restart our server BUILDSTDERR: # PARENT: killed pub/sub redis server, signal child to proceed BUILDSTDERR: # CHILD: launch wait_for_messages(2), with reconnect... BUILDSTDERR: # CHILD: reconnected (with a 10s timeout) BUILDSTDERR: # PARENT: has relaunched the server... BUILDSTDERR: # CHILD: after 2 sec, nothing yet, retrying BUILDSTDERR: # CHILD: launch wait_for_messages(2), with reconnect... BUILDSTDERR: # CHILD: after 2 sec, nothing yet, retrying BUILDSTDERR: # CHILD: launch wait_for_messages(2), with reconnect... BUILDSTDERR: # PARENT: waiting for child 20297... BUILDSTDERR: # CHILD: child received the message BUILDSTDERR: # Sleeping 11 seconds, waiting for Redis to timeout... BUILDSTDERR: # waiting for sleep command BUILDSTDERR: ++ cat /builddir/build/BUILDROOT/perl-Redis-1.991-10.fc31.noarch/redis.pid + kill -TERM 20252 + RPM_EC=0 BUILDSTDERR: ++ jobs -p + for pid in $(jobs -p) + kill -9 20250 BUILDSTDERR: /var/tmp/rpm-tmp.tdIwBR: line 45: kill: (20250) - No such process [...] All tests successful. Files=18, Tests=289, 80 wallclock secs ( 0.25 usr 0.09 sys + 14.26 cusr 3.33 csys = 17.93 CPU) Result: PASS RPM build errors: BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.tdIwBR (%check) It seems rpm-build appends some script after a %check section that tries to clean up running processes and there is a race between gathering PIDs and killing them. This seems to be triggered up upgrading rpm-build from 4.14.2.1-10.fc31 to 4.14.90-0.git14653.13... Maybe he %check script should wait() on the daemon PID after killing it. -- 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 1719806] perl-Mail-Box-IMAP4-3.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1719806 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Mail-Box-IMAP4-3.006-1 ||.fc31 Resolution|--- |RAWHIDE Last Closed||2019-06-13 08:47:47 -- 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] Re: please review: Replication Status Message Improvements
> On 12 Jun 2019, at 17:36, Mark Reynolds wrote: > > http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html Looks great! Instead of "Success" we could use "Healthy" because replication isn't a success/fail, it's a longterm "good/bad" IE healthy/failing state. So perhaps instead of success/warning/error, we have "healthy/delayed/warning/error" instead? Additionally, on warning + error, we log those to error log by default so that an admin can "see" past errors, and when they "resolve" a resolution is also posted to the error log too? Date is json should be ISO 8601 format instead? 2019-06-13T07:53:20+00:00 I hope this helps! > ___ > 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
[389-devel] Please review: 50441 - update dockerfile
https://pagure.io/389-ds-base/pull-request/50441 — 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
