Re: Koji side tag -- how to use an older build?
On Thu, Jul 11, 2024 at 03:45:35PM -0700, Kevin Fenzi wrote: > On Thu, Jul 11, 2024 at 10:55:03PM GMT, Jan Pazdziora wrote: > > > > But when I run the scratch build, I still get the latest greatest > > build from f40-updates. So it seems tagging into my child tag (target) > > does not "override" the build seen, I still get newer build from the > > parent tags. > > Did you wait for the next newrepo? > It's not instant. You have to tag the package and wait-repo for the next > newrepo for that sidetag. I thought I did but apparently I did not. When I tried the same scratch-build now, it got the dependency package in the desired version. > > How can I stop any newer build of that package to propagate from > > f40 (or f40-updates) to my side tag and force the old build I need > > to take precedence? > > You shouldn't need to, koji doesn't know anything about 'versions'. It > only knows what is the most recently tagged in build of that package. Great, that's how I remembered it from my past. Thanks for the confirmation and for your help. -- Jan Pazdziora | OpenShift AI | 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Koji side tag -- how to use an older build?
Hello, my Koji knowledge seems to be rusty and I used to be an admin in my Koji instance, so I'm coming for an advice how to achieve what I need in Fedora's Koji with the permissions given me by fedpkg. I'd need to debug a FTBFS issue, so I'd like to run a fedpkg scratch-build --target=... with a side tag target where I'd have an older version of a specific dependency package. I've used fedpkg request-side-tag to get me a side tag off f40-build, then I used koji tag-build to tag a specific older build of openvdb I want to have for my scratch build ... But when I run the scratch build, I still get the latest greatest build from f40-updates. So it seems tagging into my child tag (target) does not "override" the build seen, I still get newer build from the parent tags. How can I stop any newer build of that package to propagate from f40 (or f40-updates) to my side tag and force the old build I need to take precedence? -- Jan Pazdziora | OpenShift AI | 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 End Of Life in one week
On Tue, May 14, 2024 at 11:03:07PM +0530, Samyak Jain wrote: > Hello all, > > Fedora Linux 38 will go end of life for updates and support on > 2024-05-21. This announce comes as a surprise becuase it does not match the https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html schedule which says the EOL should be today. This is also the information that https://endoflife.date/fedora seems to use. Where did the different date of 2024-05-21 come from and where was it tracked? > [1]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule > [2]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades Neither of these have information specific about Fedora 38. -- Jan Pazdziora | OpenShift AI | 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned: multiple perl modules
Hello, I've orphaned perl-BackPAN-Index perl-Cache-FastMmap perl-Git-PurePerl perl-Git-Repository perl-Net-GitHub perl-SOAP-Lite perl-Spreadsheet-ParseExcel perl-Spreadsheet-ParseExcel-Simple perl-Spreadsheet-WriteExcel-Simple perl-String-Diff The packages have co-admins but when I reached out to them, they were not interested in being the main admins. So these packages are looking for someone who can focus on Fedora more than me. There are currently no open bugzillas against them and they are low to extremely low maintenance. -- Jan Pazdziora | OpenShift AI | 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned libdnf-plugin-swidtags, planning to orphan swid-tools
On Tue, Jul 11, 2023 at 04:27:34PM +0200, Jan Pazdziora wrote: > > Hello, > > the SWID tag enablement introduced by > https://fedoraproject.org/wiki/Changes/SWID_Tag_Enablement did not lead > to a wider SWID tag adoption, and other technologies (IMA, SPDX) seem > to be more relevant for the purpose SWID tags were expected to play, > four years later. > > For that reason I've orphaned libdnf-plugin-swidtags. > > I'm looking for ways to reach out to the rpm-software-management-sig > who are co-maintainers of https://src.fedoraproject.org/rpms/swid-tools > to see what their interest / plang might be about swid-tools but > overall I'm leaning towards orphaning swid-tools as well shortly. I've now orphaned swid-tools in Fedora as well. -- Jan Pazdziora | Sr. Principal 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned libdnf-plugin-swidtags, planning to orphan swid-tools
Hello, the SWID tag enablement introduced by https://fedoraproject.org/wiki/Changes/SWID_Tag_Enablement did not lead to a wider SWID tag adoption, and other technologies (IMA, SPDX) seem to be more relevant for the purpose SWID tags were expected to play, four years later. For that reason I've orphaned libdnf-plugin-swidtags. I'm looking for ways to reach out to the rpm-software-management-sig who are co-maintainers of https://src.fedoraproject.org/rpms/swid-tools to see what their interest / plang might be about swid-tools but overall I'm leaning towards orphaning swid-tools as well shortly. The fact that latest python and dnf5 changes lead to FTBFS or FTI https://bugzilla.redhat.com/show_bug.cgi?id=2220605 are also contributing to my decision to orphan. -- Jan Pazdziora | Sr. Principal 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: cups-2.4.2-11.fc39.src.rpm depends on autoconf-2.71 or newer, not mentioned in .spec file, fails build
On Sun, Mar 26, 2023 at 02:44:34PM +0300, ijaaskelai...@outlook.com wrote: > Kind regards, The Improvement Skeleton. Please show the exact steps you use to build the cups package and the exact error message you get. Technically you are correct because configure.ac has AC_PREREQ([2.71]). But autoconf is pulled in by the automake which is listed as BuildRequires in cups.spec file, and since Fedora rawhide only has autoconf-2.71-5.fc38.noarch, there really is not an older autoconf around to ruin your day. -- Jan Pazdziora | Sr. Principal 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Change in glibc about _STAT_VER in Fedora rawhide?
On Fri, Nov 27, 2020 at 12:28:36PM +0100, Florian Weimer wrote: > * Jan Pazdziora: > > >> There's a Fedora-specific hack in rawhide glibc to bring back the > >> __xstat and related symbols for linking. This in the process of being > >> upstreamed. > > > > Does that include __fxstatat64? And is the hack already in > > glibc-2.32.9000-16.fc34 or is it on the way to rawhide? > > Looking at the current rawhide buildroot, it's already there: > > # eu-readelf --symbols=.dynsym /lib64/libc.so.6 | grep __fxstat64 > 1059: 000f1880 84 FUNCGLOBAL DEFAULT 15 > __fxstat64@@GLIBC_2.2.5 > > The @@ means it's available for linking. Nod, I see it there. What would you recommend to software that wants to compile against these symbols? -- Jan Pazdziora | adelton at #security, #brno Product Owner, Platform Security Readiness, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Change in glibc about _STAT_VER in Fedora rawhide?
On Wed, Nov 25, 2020 at 11:57:38AM +0100, Florian Weimer wrote: > * Jan Pazdziora: > > > it seems that both fakeroot and fakechroot fail to build in Fedora > > rawhide (at least partially) because _STAT_VER is no longer declared > > in the current glibc (or rather, its headers): > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1889862 > > https://bugzilla.redhat.com/show_bug.cgi?id=1901049 > > > > The bugzillas are filed against their respective components but > > I wonder if we have any guidance from the glibc point of view about > > how these components should proceed. Or is the loss of _STAT_VER an > > omission and will it come back? > > _STAT_VER will not come back, these packages have to define the value > locally. glibc won't add any _STAT_VER values. Thank you. So do you recommend for fakechroot to hardcode something like --- a/src/libfakechroot.h +++ b/src/libfakechroot.h @@ -224,4 +224,14 @@ int fakechroot_try_cmd_subst (char *, const char *, char *); int snprintf(char *, size_t, const char *, ...); #endif +#ifndef _STAT_VER +#if defined (__aarch64__) +#define _STAT_VER 0 +#elif defined (__x86_64__) +#define _STAT_VER 1 +#else +#define _STAT_VER 3 +#endif +#endif + #endif for all the arches? > There's a Fedora-specific hack in rawhide glibc to bring back the > __xstat and related symbols for linking. This in the process of being > upstreamed. Does that include __fxstatat64? And is the hack already in glibc-2.32.9000-16.fc34 or is it on the way to rawhide? -- Jan Pazdziora | adelton at #security, #brno Product Owner, Platform Security Readiness, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Change in glibc about _STAT_VER in Fedora rawhide?
Hello, it seems that both fakeroot and fakechroot fail to build in Fedora rawhide (at least partially) because _STAT_VER is no longer declared in the current glibc (or rather, its headers): https://bugzilla.redhat.com/show_bug.cgi?id=1889862 https://bugzilla.redhat.com/show_bug.cgi?id=1901049 The bugzillas are filed against their respective components but I wonder if we have any guidance from the glibc point of view about how these components should proceed. Or is the loss of _STAT_VER an omission and will it come back? -- Jan Pazdziora Product Owner, Platform Security Readiness, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: @core install picking up desktop packages
On Fri, Apr 03, 2020 at 03:12:35PM +0200, Petr Pisar wrote: > > Maybe libsecret spec could provide an empty libsecret-never-fail subpackage > that would hard-require a libsecret server and the applications like geary > would > require that subpackage. (Alternatively libsecret-devel could provide a RPM > macro that the applications use to add a direct dependency on a server.) But > this abstractions is quite academic provided the only libsecret server in > Fedora is gnome-keyring. I wouldn't focus on a particular package because the situation can repeat with any other package in the future, and would make the question more generic. Is it expected, are we OK with the fact, that with default settings of weak dependencies enabled in dnf and anaconda, installing @group can eventually pull in way more packages than originally listed in the group, beyond the hard dependencies? Should following the weak dependencies be a boolean yes/no setting, or should it be a score and should the resolver have an option to favour weak dependencies when resolving the first level of depenencies from the original package list but decrease (perhaps radically) favouring them in next and next-next-levels, potentially even taking into account if the intermediate dependencies were explicit ones or implicit libraries? In other words, if I list packages A, B, C in transaction, I might want to have their weak dependencies thrown onto the system as well. But if A requires libX.so and libY.so, and package X requires G and that has weak dependency on K, I might not care about K. If I explicitly say I want G, then again, sure, give me K as well. -- Jan Pazdziora Product Owner, Platform Security Readiness, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: @core install picking up desktop packages
On Thu, Apr 02, 2020 at 02:59:33PM -0400, Stephen Gallagher wrote: > > > On Thu, 2020-04-02 at 13:24 -0400, Steve Grubb wrote: > > > > > > > Hello, > > > > > > > > I've been doing some testing of F32 and was curious about something. I > > > > have a kickstart file that just installs @core to be a minimal system. > > > > While looking over the resulting system, there are fonts, wayland, gtk3 > > > > and others. Is this intentional? The system probably doesn't have > > > > everything that's needs to function as a desktop. Why are all these > > > > installed by @core? [...] > That said, I think gtk3 is always part of the standard installation > because it's needed by Anaconda. Anaconda is not pulled in by @core. The dependency chain from @core to gtk3 and fonts actually goes from gnupg2, required by dnf, which recommends pinentry, which requires libsecret-1.so.0()(64bit), which then recommends gnome-keyring, which requires /usr/libexec/gcr-ssh-askpass, which comes from gcr, which requires libgtk-3.so.0()(64bit) and libpango-1.0.so.0()(64bit). It can also be demonstrated with $ podman run --rm -ti registry.fedoraproject.org/fedora:32 dnf reinstall gnupg2 Running dnf install with --setopt=install_weak_deps=false (or in kickstart %packages --excludeWeakdeps) removes those extra 82 packages from the transaction. -- Jan Pazdziora Product Owner, Platform Security Readiness, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Building for EPEL 8 -- missing kernel-headers-4.18.0-80.11.1.el8_0.x86_64.rpm
On Fri, Sep 20, 2019 at 09:21:21AM -0400, Stephen John Smoogen wrote: > On Fri, 20 Sep 2019 at 06:53, Jan Pazdziora wrote: > > > > my attempt to (scratch) build an EPEL 8 package failed with > > > > > > https://kojipkgs.fedoraproject.org//work/tasks/9259/37759259/root.log > > > > DEBUG util.py:593: Error: Error downloading packages: > > DEBUG util.py:593:Status code: 404 for > > https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/kernel-headers-4.18.0-80.11.1.el8_0.x86_64.rpm > > DEBUG util.py:741: Child return code was: 1 > > > > I assume it's not something I could affect from my fedpkg side. > > > > Is that a known issue? What is the best way to report it? > > > > It isn't a known issue.. I would report it as a releng issue so > whatever I wrote to try and make this work can be fixed. > > Looking at the tree > > -rw-r--r--. 1 root sysadmin-main 434036 2019-09-20 09:25 > latest/x86_64/RHEL-8-001/non_modular/kernel-4.18.0-80.11.2.el8_0.x86_64.rpm [...] > latest/x86_64/RHEL-8-001/non_modular/kernel-tools-libs-devel-4.18.0-80.11.2.el8_0.x86_64.rpm > > So the .2 kernel is the one which should be used. I don't see a > timestamp in the file you provided so I am not sure if this build > problem occurred near the 09:25 listed above or not. Thanks Stephen for looking at it. I don't see the same problem today and I was able to build the package. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Building for EPEL 8 -- missing kernel-headers-4.18.0-80.11.1.el8_0.x86_64.rpm
Hello, my attempt to (scratch) build an EPEL 8 package failed with https://kojipkgs.fedoraproject.org//work/tasks/9259/37759259/root.log DEBUG util.py:593: Error: Error downloading packages: DEBUG util.py:593:Status code: 404 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/kernel-headers-4.18.0-80.11.1.el8_0.x86_64.rpm DEBUG util.py:741: Child return code was: 1 I assume it's not something I could affect from my fedpkg side. Is that a known issue? What is the best way to report it? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Over 500 orphaned packages seeking new maintainers
On Mon, Jul 29, 2019 at 12:37:33PM +0200, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> See the full report:
> https://churchyard.fedorapeople.org/orphans-2019-07-28.txt
> Grep it for your FAS username and follow the dependencies.
>
> Request package ownership via https://pagure.io/releng/issues
>
> Package (co)maintainers Status
> Change
>
> javaewah eclipse-sig, galileo, orphan 0 weeks ago
[...]
Hello,
I'm a little bit confused. The javaewah is listed above with the four
comaintainers, but then below it is listed next to many people's
usernames, including mine:
> The following packages require above mentioned packages:
> Report too long for e-mail, see:
> https://churchyard.fedorapeople.org/orphans-2019-07-28.txt
> Grep it for your FAS username and follow the dependencies.
>
> Affected (co)maintainers
> abbra: javaewah
> abo: minlog, extra166y, jdo2-api, groovy18, parboiled, http-builder,
> gmetrics, codenarc, reflectasm, jcsp, jhighlight, aws-sdk-java, json-lib,
> mysql-connector-java, jatl, pegdown, jcifs, kryo, google-oauth-java-client,
> native-platform, google-http-java-client
> abompard: javaewah
> abrt-team: javaewah
> acaringi: log4j12, mvel, concurrentlinkedhashmap-lru, minlog, aalto-xml,
> extra166y, jdo2-api, groovy18, hppc, jmock, metrics, jctools, logback,
> simple-xml, jmh, parboiled, javaparser, snowball-java, airline, jsonp,
> reflections, http-builder, compress-lzf, gmavenplus-plugin, lzma-java,
> glassfish-management-api, glassfish-jax-rs-api, high-scale-lib,
> glassfish-gmbal, gmetric4j, gmetrics, rxjava, codenarc, disruptor, fastutil,
> grizzly-npn, jersey1, simple, jersey, jackson-databind, cli-parser, jcsp,
> reflectasm, replacer, jamm, grizzly, java_cup, mimepull, treelayout,
> aws-sdk-java, jhighlight, json-lib, mysql-connector-java, jatl,
> randomizedtesting, pegdown, jcifs, kryo, janino, mustache-java, remotetea,
> jackson-modules-base, jdbi, rabbitmq-java-client, google-oauth-java-client,
> native-platform, glassfish-pfl, google-http-java-client,
> httpcomponents-asyncclient
> adamwill: javaewah
> adelton: javaewah
Checking the full report at
https://churchyard.fedorapeople.org/orphans-2019-07-28.txt
it lists
perl-Git-Repository (maintained by: adelton, iarnell)
perl-Git-Repository-1.323-3.fc31.noarch requires git =
2.22.0-1.fc31
perl-Git-Repository-1.323-3.fc31.src requires git =
2.22.0-1.fc31
but I don't see git as being orphaned.
Am I reading the report wrong?
--
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Gating tests from tarball in Fedora - how to set up them?
On Fri, May 31, 2019 at 08:34:59AM -0700, Adam Williamson wrote: > > The 'test case names' here are the names as they appear in resultsdb. > Both of those exist, though dist.depcheck hasn't actually been used > since July 2017, so we should probably replace that name as an example: > > https://taskotron.fedoraproject.org/resultsdb/results?&testcases=dist.depcheck&since=2017-01-02T00:00:00,2019-05-31T23:59:59 > https://taskotron.fedoraproject.org/resultsdb/results?&testcases=org.centos.prod.ci.pipeline.allpackages-build.package.test.functional.complete&since=2019-02-01T00:00:00,2019-05-31T23:59:59 > > I am not 100% sure what resultsdb test name the results of a per- > package test like this would show up under, but as these tests are run > in the CI pipeline it probably actually *is* > org.centos.prod.ci.pipeline.allpackages- > build.package.test.functional.complete , which would be why that > existing package uses it. Thanks for confirming this, it seems that failed org.centos.prod.ci.pipeline.allpackages-build.package.test.functional.complete gates the update correctly: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e00e77df62 What is the best way to get this added to the general documentation of Fedora CI and gating? Should I take this to ci@lists? -- Jan Pazdziora Sr. Principal Software Engineer, Security Engineering, 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
Re: What to do when Fedora CI run failed?
On Tue, Jun 04, 2019 at 03:48:52PM +0200, Kamil Paral wrote: > On Tue, Jun 4, 2019 at 3:29 PM Jan Pazdziora wrote: > > > > What is the recommended way to remedy the situation, for example for > > reruning that pipeline run? > > Hi Jan, > you might want to cc the CI list: > https://lists.fedoraproject.org/archives/list/ci%40lists.fedoraproject.org/ Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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
Re: What to do when Fedora CI run failed?
On Tue, Jun 04, 2019 at 03:28:12PM +0200, Jan Pazdziora wrote: > > Hello, > > I have run fedora-rawhide-build-pipeline > > > https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/4426/pipeline/ > > that failed in the > > cloud-image-compose > > stage, something which (I believe) have very little control over. > > What is the recommended way to remedy the situation, for example for > reruning that pipeline run? My other build on f30 https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-f30-build-pipeline/detail/fedora-f30-build-pipeline/491/pipeline/183 resulted in orange exclamation mark status, in spite of the fact that the checkboxes in each of the states are all green. What does it mean and how should I fix it? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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
What to do when Fedora CI run failed?
Hello, I have run fedora-rawhide-build-pipeline https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/4426/pipeline/ that failed in the cloud-image-compose stage, something which (I believe) have very little control over. What is the recommended way to remedy the situation, for example for reruning that pipeline run? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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
Re: Gating tests from tarball in Fedora - how to set up them?
On Fri, May 31, 2019 at 12:53:35PM +0200, Jan Tulak wrote:
> Hi guys
>
> I'm trying to enable gating tests for package system-storage-manager.
> The tarball contains upstream tests and I would like to use these
> (with the ability to apply patches to them, same as to the rest of the
> code). I have a gating.yaml and tests.yml that works in RHEL exactly
> as I want it, but when I try to apply them to Fedora, I can't get it
> to work.
>
> It looks as the tests are not included in the VM built for the test.
> If I change tests.yml and use only "run: some_system_command," then
> the system command is executed.
>
> My tests.yml looks very similar to swid-tools, where it works
> (according to jenkins logs), so I'm cc-ing Jan Pazdziora just in case.
>
> I tried to find some solution on
> https://docs.fedoraproject.org/en-US/ci/ (and subpages), but if it is
> there, I didn't notice. I also found some other pages as
> https://docs.pagure.org/greenwave/package-specific-policies.html, with
> the same result.
>
> I'm using this PR to start the tests:
> https://src.fedoraproject.org/rpms/system-storage-manager/pull-request/1
> A failed run:
> https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-f30-pr-pipeline/detail/fedora-f30-pr-pipeline/102/pipeline
>
> Any ideas what I'm doing wrong? gating.yaml and tests.yml bellow.
[2019-05-31T08:59:54.127Z] stdout: |-
[2019-05-31T08:59:54.127Z] Test: smoke
[2019-05-31T08:59:54.127Z] Command: ./test.py --system --logs
[2019-05-31T08:59:54.127Z] Work dir: /var/str/source
[2019-05-31T08:59:54.127Z] Artifacts dir: /tmp/artifacts
[2019-05-31T08:59:54.127Z] Timeout: 0
[2019-05-31T08:59:54.127Z] /usr/bin/env: python: No such file or directory
[2019-05-31T08:59:54.127Z] Run test 'smoke': done. Test's exit code: 127
[2019-05-31T08:59:54.127Z] smoke (problem with test execution)
Could the missing python be the culprit?
> --
> File gating.yml:
> --- !Policy
> product_versions:
> - fedora-*
> decision_context: bodhi_update_push_testing # was osci_compose_gate
> rules:
> - !PassingTestCaseRule {test_case_name: osci.brew-build.tier0.functional}
>
> I tried to replace the osci.brew-build.tier0.functional with some
> build.foo cases, but it didn't change anything.
I'd like to know how to enable gating in Fedora as well.
So far I've only seen example in
https://docs.fedoraproject.org/en-US/ci/gating/
which says
--- !Policy
product_versions:
- fedora-*
decision_context: bodhi_update_push_testing
rules:
- !PassingTestCaseRule {test_case_name: dist.depcheck}
but that test_case_name: dist.depcheck seems suspicious, it looks more
like a dependency check than gating based on the tests/tests.yaml
results.
I've found
https://src.fedoraproject.org/rpms/python-ansi2html/blob/master/f/gating.yaml
which says
- !PassingTestCaseRule {test_case_name:
org.centos.prod.ci.pipeline.allpackages-build.package.test.functional.complete}
which sounds more related to the test result hostname
jenkins-continuous-infra.apps.ci.centos.org
-- but that
org.centos.prod.ci.pipeline.allpackages-build.package.test.functional.complete
does not seem to be documented anywhere, just used in a few
dist-git repositories.
Any hints about some better documentation about configuring gating for
Fedora would be appreciated.
--
Jan Pazdziora | adelton at #brno, #swid
Sr. Principal Software Engineer, Security Engineering, 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
Re: F30 Self-Contained Change proposal: SWID tag enablement
On Thu, Feb 07, 2019 at 05:35:23PM +0100, Jan Pazdziora wrote: > On Tue, Feb 05, 2019 at 07:16:09PM +0100, Miro Hrončok wrote: > > On 05. 02. 19 18:47, Jan Pazdziora wrote: > > > > > ** add SWID metadata awareness to createrepo (but this will not be > > > > Do you mean createrepo_c? createrepo is going away. > > > Yes. Is it OK to update the change page to fix that? > > > > Sure thing, go ahead. That's kinda the point of having a discussion on devel > > - spot problems, amend the proposal. > > Good. Change page updated. > > On Tue, Feb 05, 2019 at 10:01:10PM -0500, Neal Gompa wrote: > > > > Technically, there is the rpm-metadata@ mailing list on > > lists.baseurl.org, but I don't think anyone looks there anymore. > > rpm-ecosystem@ on lists.rpm.org is the right place these days. > > OK, http://lists.rpm.org/pipermail/rpm-ecosystem/2019-February/000711.html > sent. Hello, the rpm-ecosystem has been silent so far. Any idea who might be the right person to talk about possibly using http://rpm.org/metadata/swidtags URI? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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
Re: signing status
On Tue, Feb 12, 2019 at 09:19:03AM +, Peter Robinson wrote: > On Tue, Feb 12, 2019 at 8:49 AM Jan Pazdziora wrote: > > > > All of them failed on armv7hl, with some package (for example > > glibc-2.29-1.fc30.1.armv7hl.rpm) missing in the mock step. > > > > How should maintainers proceed in such situation? > > If the problem is now fixed you should just be able to do "fedpkg > build" to rebuild it and it'll proceed as usual. Thanks, that passed now. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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
Re: signing status
On Mon, Feb 11, 2019 at 10:35:55AM -0800, Kevin Fenzi wrote: > >> > >> * The mass rebuild happened and finished. > > > > Is there anywhere some summary stats about mass update? > > How many packages has been sent to rebuild vs those which rebuild failed? > > There is: > > https://kojipkgs.fedoraproject.org/mass-rebuild/f30-failures.html > > and > > https://kojipkgs.fedoraproject.org/mass-rebuild/f30-need-rebuild.html > > The FTBFS bugs are being filed now I think... My packages were caught in the crossfire: https://bugzilla.redhat.com/show_bug.cgi?id=1675617 https://bugzilla.redhat.com/show_bug.cgi?id=1675618 https://bugzilla.redhat.com/show_bug.cgi?id=1675634 All of them failed on armv7hl, with some package (for example glibc-2.29-1.fc30.1.armv7hl.rpm) missing in the mock step. How should maintainers proceed in such situation? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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
Re: F30 Self-Contained Change proposal: SWID tag enablement
On Tue, Feb 05, 2019 at 07:16:09PM +0100, Miro Hrončok wrote: > On 05. 02. 19 18:47, Jan Pazdziora wrote: > > > > ** add SWID metadata awareness to createrepo (but this will not be > > > Do you mean createrepo_c? createrepo is going away. > > Yes. Is it OK to update the change page to fix that? > > Sure thing, go ahead. That's kinda the point of having a discussion on devel > - spot problems, amend the proposal. Good. Change page updated. On Tue, Feb 05, 2019 at 10:01:10PM -0500, Neal Gompa wrote: > > Technically, there is the rpm-metadata@ mailing list on > lists.baseurl.org, but I don't think anyone looks there anymore. > rpm-ecosystem@ on lists.rpm.org is the right place these days. OK, http://lists.rpm.org/pipermail/rpm-ecosystem/2019-February/000711.html sent. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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
Re: F30 Self-Contained Change proposal: SWID tag enablement
On Tue, Feb 05, 2019 at 11:36:50AM +0100, Igor Gnatenko wrote: > On Mon, Jan 28, 2019, 18:32 Ben Cotton > > ** add SWID metadata awareness to createrepo (but this will not be > > used in Fedora, only enabled for user use), agreeing metadata format > > with dnf team > > Since this needs to be portable, please start discussion on > rpm-ecosys...@lists.rpm.org a.d don't do something what is DNF-specific. Thank you for the pointer. Does rpm-ecosystem@ really deal with yum/dnf repository metadata XML schemas? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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
Re: F30 Self-Contained Change proposal: SWID tag enablement
On Tue, Feb 05, 2019 at 09:18:23AM +, Zbigniew Jędrzejewski-Szmek wrote: > > > > == Scope == > > * Proposal owners: > > ** Add python SWID tools (swidq, rpm2swidtag) > > Does "add" mean "package" here? Or are they to be added to some other > package? Are the review requests / pull requests to be reviewed > somewhere? New package is what we are thinking about. I don't have review request yet, the upstream development currently happens at https://github.com/swidtags/rpm2swidtag and I have a couple more things to flesh out before being ready for review. > > ** add SWID metadata awareness to createrepo (but this will not be > > Do you mean createrepo_c? createrepo is going away. Yes. Is it OK to update the change page to fix that? > > used in Fedora, only enabled for user use), agreeing metadata format > > with dnf team > > F30 beta is in exactly 2 weeks. I doubt "agreeing" and implementation > can happen in this timeframe. It should be OK to put in parts of the > implementation, even if things are not complete for this release. > But for "advertising purposes", maybe it's better to bump it to F31, > so that we don't advertise something that is not fully implemented? > > > ** add dnf and libdnf plugins (no core dnf/libdnf changes expected) > > A bit more detail here would be useful. The latest improvements to dnf and libdnf plugin API seems to cover everything that we need to be able to generate SWID tags locally after every transaction, as well as pull in SWID tags from repository metadata, if present. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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
Re: What does 141 mean?
On Sun, Sep 16, 2018 at 11:53:08PM +0200, Björn Persson wrote: > I have a Kerberos authentication problem. > > On one computer running Fedora 27, I run kinit to authenticate to the > Fedora servers. After I enter my passphrase, kinit returns exit status > 141. Then I run "fedpkg build", and get these error messages: > > Kerberos authentication fails: (-1765328352, 'Ticket expired') > Could not execute build: Could not login to > https://koji.fedoraproject.org/kojihub > > On another computer also running Fedora 27, I run the exact same kinit > command. After I enter my passphrase, kinit returns exit status 0. I can > then run "fedpkg build" successfully. Can you check the current time on the problematic machine? Is it in sync? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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
Re: F29 System Wide Change: i686 Is For x86-64
On Mon, Jun 04, 2018 at 10:35:34AM +0200, Jan Kurik wrote: > = Proposed System Wide Change: i686 Is For x86-64 = > https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64 > > > Owner(s): > * Florian Weimer > > > Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs. > > > > == Detailed description == > Currently, the i686 RPM packages are built in such a way that they are > compatible with very old i686 systems, such as the Pentium III. The > only addition over the i686/Pentium Pro baseline is a requirement to > support long NOPs, for Intel CET. However, the majority of > installations of i686 packages is for use on x86_64 systems, as > multi-lib RPMs. Furthermore, there are reports that the i686 kernel > does not run stable on old hardware which is not x86-64-capable ( > https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/ > ). > This proposal suggests to accept this reality and build the i686 > packages in such a way that they require the ISA level of (early) > x86-64 CPUs. > > > == Scope == > * Proposal owners: > Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the > new compiler flags. Except for mstackrealign, there is substantial > experience with this configuration downstream. > > * Other developers: > Other developers can enable SSE2 optimization in their packages if > they want, where this has been a compile-time option only. > > * Release engineering: > https://pagure.io/releng/issues/7543 #7543 > > ** List of deliverables: TBD > > * Policies and guidelines: > i686 is no longer a primary architecture. The Packaging Guidelines do > not currently require support for non-SSE2 x86 systems, so no change > is required there. Could the title and nature of this proposed change be modified to Dropping support for non-SSE2 x86 systems rather than removing i686 from primary architectures and implying that we no longer do i686-only distribution? Reading this thread, the SSE2/non-SSE2 distinction is where the change is aiming anyway, isn't it? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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/message/5G4KWIBDQ25V6XLR4NIUXOST3D7B2SVH/
Re: Detecting building package on rawhide
On Wed, Jun 06, 2018 at 02:48:25PM +0200, Florian Weimer wrote:
> On 06/06/2018 02:24 PM, Jan Pazdziora wrote:
> > Checking rpm --showrc, I can see rawhide sets %{fedora} to 29 and
> > there does not seem any mention of rawhide in the showrc output.
> >
> > What would people recommend to distinguish rawhide from non-rawhide?
>
> The mass rebuild, if there is any, happens before rawhide turns into
> non-rawhide, so there is simply no distinction whatsoever, and there cannot
> be.
OK, thanks.
--
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, 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/message/O2IYAYDCJEQJTLSDV5UG6CBWHWS65ESU/
Detecting building package on rawhide
Hello,
I try to create SWID Tags for Fedora and I'd like to be able to
distinguish when running the rpm build on rawhide, as opposed to
"released" version.
Checking rpm --showrc, I can see rawhide sets %{fedora} to 29 and
there does not seem any mention of rawhide in the showrc output.
What would people recommend to distinguish rawhide from non-rawhide?
For now I'm running the builds in copr but eventually I'd like for
it to work in koji as well.
Thank you,
--
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, 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/message/ON4QIMJVCBCRHDTJKEE2S6GCT7JC6ABI/
Re: Change in Copr retention policy?
On Fri, Jun 01, 2018 at 12:30:28PM +0200, Miroslav Suchý wrote: > > This means that we still have repos for fedora-18-* and epel-5-*. > > Is this reasonable? Or are we just wasting storage? According to our logs > those repositories are still accessed (yes > even that fedora-18). It could be it's some version independent noarch content that just works fine even on latest OSes? > Personally, I think that keeping the repositories one year after EOL date is > just fine. That means we delete fedora-24-* > and older and epel-5-*. What do you think? Can you use some "hasn't been accessed in the past 180 days" filter for them, to see how much space could be freed without disrupting people who for some reason still use the old content? In any case, it'd be nice to notify the owners of those repos to give them chance to review what they have and potentially rebuild their content on newer buildroots, or just mark their repos "alive" and extend the expiration for another 180 days. Or something to that effect. > Do you have a use case for using ancient fedoras repos? What is better for > you: to have ancient fedora repos or to have From time to time, I start containers as old as Fedora 24 to test some behaviour -- namely it was the last Fedora where systemd reliably produced status log in docker, but it's also useful to for checking regressions. I don't use copr repos for that but i can imagine there are people who do. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, 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/message/HKLIQKRQBUJJNPGTQ27FXYGUW657VLP3/
Re: systemd in non-privileged container
On Mon, Apr 30, 2018 at 10:56:10AM -0400, Daniel Walsh wrote: > > Perhaps it is time to update my blog on running systemd in a unprivileged > container. Let's get the base images fixed so that at least that ENV container ... is there by default, to minimize the number of steps that are needed. -- Jan Pazdziora | adelton at #aos*, #brno Sr. Principal Software Engineer, OpenShift Security Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On Fri, Apr 27, 2018 at 05:27:19PM +0200, Pavel Raiskup wrote: > Hi all, > > just wanted to let you know about trivial experiment [1] with systemd in > container. Non-privileged systemd can now pretty fine run in docker > container (tested on Fedora 27 box). > > Could we support this under fedora-kickstarts, or as a layered image? > > [1] https://github.com/praiskup/systemd-container The pull request https://github.com/fedora-cloud/docker-brew-fedora/pull/45 to add the container environment variable to Fedora based images was merged many month ago but it does not seem to have affected the images that get built. Does anyone have any idea what is the based container image build process these days and in which repository we need to do the same change to have the environment variable set by default? -- Jan Pazdziora Senior Principal Software Engineer, OpenShift Security Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On Sun, Feb 18, 2018 at 06:09:40PM +0100, Igor Gnatenko wrote: > > List of packages and respective maintainers: > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt > > adeltonmod_auth_openidc mod_authnz_pam mod_intercept_form_submit > mod_lookup_identity perl-Cache-Mmap perl-Crypt-DES perl-Sys-CPU I've updated and built mod_authnz_pam mod_intercept_form_submit mod_lookup_identity perl-Cache-Mmap perl-Crypt-DES I'm leaving mod_auth_openidc to John and perl-Sys-CPU to Emmanuel, as I don't want to step on their toes. -- Jan Pazdziora Senior Principal Software Engineer, OpenShift Security Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modularizing the world fast and iteratively
On Thu, Aug 24, 2017 at 01:06:21PM +0200, Kevin Kofler wrote: > Pavel Raiskup wrote: > > Ok, I agree that Fedora needs modules for life-cycle separation. > > I don't. I consider what you call "life-cycle separation" (I'd rather call > it "inconsistent EOLs") a bug rather than a feature. > > This is yet another of those "features" that sound great on paper, but lead > to a horrible user experience in practice. Right now, it is easy to know > when you have to upgrade, as there is one EOL for the entire distro. With > inconsistent per-module EOLs, as soon as you have a non-trivial amount of > modules installed, it is impossible to track down when you need to upgrade > what. So either you end up with an unsupported version of the module without > even noticing, or you get forcefully upgraded at what will often be the > worst possible time. But you get upgraded even now. Firefox gets major-version upgrades even within the life of the Fedora version, as do other packages. Yes, it might become a mess if the tooling is not right or clear. But it is also an opportunity to potentially get a choice between stay on the old, stable, vs. get the latest greatest. -- Jan Pazdziora Senior Principal Software Engineer, OpenShift Security Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Modularity] A proposal for stream naming
On Wed, Jun 28, 2017 at 04:07:43PM -0400, Matthew Miller wrote: > > Each such "collection" module MUST have one or both of the following: > > * A "latest" rolling stream (As above, this would be separate from > "rawhide", as "latest stable", but could update frequently and > arbitrarily.) > > * One or more streams corresponding to "end of life no earlier than", > in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or "uYYMM" for > 'until'? Or "fYYMM" for 'fedora' — which might make sense if we get > to my dream of mixing and matching with CentOS modules) Please make the year a full four-digit value. Typing that extra "20" will not hurt anybody and the chance for confusion will be much smaller. -- Jan Pazdziora Senior Principal Software Engineer, OpenShift Security Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
registry.fedoraproject.org/fedora:25 cannot install packages
Hello, it seems registry.fedoraproject.org/fedora:25 was recently updated to some 10 month old version f3535ce68198 where packages cannot be installed due to missing /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64: https://bugzilla.redhat.com/show_bug.cgi?id=1460094 -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announce: Fedora Layered Image Release
On Tue, May 23, 2017 at 11:27:13AM -0500, Adam Miller wrote: > On Tue, May 23, 2017 at 9:38 AM, Jan Pazdziora wrote: > > > > The bugzilla was addressed -- can we give > > > > registry.fedoraproject.org/fedora:26 > > > > another try? > > Yes, it's on the agenda for today to go out with the layered image > release that will follow today's Atomic Host release. \o/ REPOSITORYTAG IMAGE ID CREATED SIZE registry.fedoraproject.org/fedora 26 7bb26fd96ae0 20 hours ago 230.5 MB Thanks, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announce: Fedora Layered Image Release
On Mon, May 15, 2017 at 03:45:32PM -0500, Adam Miller wrote: > > > > Is the infrastructure now ready for the respin? > > It appears the builds are still failing because of > https://bugzilla.redhat.com/show_bug.cgi?id=144 The bugzilla was addressed -- can we give registry.fedoraproject.org/fedora:26 another try? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announce: Fedora Layered Image Release
On Thu, May 11, 2017 at 10:04:19AM -0500, Dennis Gilmore wrote: > El mié, 10-05-2017 a las 22:47 -0500, Adam Miller escribió: > > On Tue, May 9, 2017 at 7:22 AM, Jan Pazdziora > > wrote: > > > > > > One problem with the current Fedora 26 image is that it enables > > > rawhide repo and not the 26 development repo. So anybody using that > > > image to build something which installs additional packages will > > > get > > > Fedora 27, not Fedora 26 packages installed. > > > > > > Could the registry.fedoraproject.org/fedora:26 be respun to point > > > to > > > the correct Fedora 26 package source? > > > > Absolutely. I went to look into that today but the koji builder tasks > > were having an issue for the last few weeks. It turns out that there > > was a bug in oz (which is used in image builds in koji). This has > > been > > fixed and we should be able to get updates out tomorrow. > > the bug was not in oz. I suspect it was a regression in nss, all the > gory details are in > https://pagure.io/releng/issue/6776https://pagure.io/releng/issue/6776 Is the infrastructure now ready for the respin? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announce: Fedora Layered Image Release
On Mon, May 08, 2017 at 01:59:36PM -0500, Adam Miller wrote: > On Thu, May 4, 2017 at 6:55 AM, Jan Pazdziora wrote: > > On Thu, Apr 20, 2017 at 10:39:22PM -0500, Adam Miller wrote: > >> Hello all, > >> On behalf of the Fedora Atomic WG[0] and Fedora Release > >> Engineering[1], I am pleased to announce the latest Fedora Layered > >> Image Release. This follows the latest Atomic Host Release that came > >> out yesterday[2]. > >> > >> At this time the following Container Images are available in the > >> Fedora Registry. > >> > >> > >> Base Images: > >> > >> (Note that the "latest" tag currently points to "25" and the "rawhide" > >> tag currently points to "27", if no tag is provided in your pull > >> command then it will always default to "latest") > >> > >> registry.fedoraproject.org/fedora:latest > >> registry.fedoraproject.org/fedora:rawhide > >> registry.fedoraproject.org/fedora:27 > > > > The current registry.fedoraproject.org/fedora:rawhide and > > registry.fedoraproject.org/fedora:27 image 202b880ac136 says it's > > 7 weeks old, > > > >> registry.fedoraproject.org/fedora:26 > > > > Fedora 26 image is 4 months old. > > > > What are the plans for respining these images on regular basis? > > Especially the development "releases" tend to change quite heaving and > > if we do not want to encourage the use of > > > > RUN dnf upgrade -y > > > > in every Dockerfile, we might want to make it easy for people to > > consume fresh content. > > > > Incidently, registry.fedoraproject.org/fedora:25 is rather new, just > > 13 days old. > > Yes, the current stable is planned to be respun on a two-week average. > The others as well but they aren't priority right now. There's an > automation process in the works and once that is done then all of > these will happen automatically. One problem with the current Fedora 26 image is that it enables rawhide repo and not the 26 development repo. So anybody using that image to build something which installs additional packages will get Fedora 27, not Fedora 26 packages installed. Could the registry.fedoraproject.org/fedora:26 be respun to point to the correct Fedora 26 package source? Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announce: Fedora Layered Image Release
On Thu, Apr 20, 2017 at 10:39:22PM -0500, Adam Miller wrote: > Hello all, > On behalf of the Fedora Atomic WG[0] and Fedora Release > Engineering[1], I am pleased to announce the latest Fedora Layered > Image Release. This follows the latest Atomic Host Release that came > out yesterday[2]. > > At this time the following Container Images are available in the > Fedora Registry. > > > Base Images: > > (Note that the "latest" tag currently points to "25" and the "rawhide" > tag currently points to "27", if no tag is provided in your pull > command then it will always default to "latest") > > registry.fedoraproject.org/fedora:latest > registry.fedoraproject.org/fedora:rawhide > registry.fedoraproject.org/fedora:27 The current registry.fedoraproject.org/fedora:rawhide and registry.fedoraproject.org/fedora:27 image 202b880ac136 says it's 7 weeks old, > registry.fedoraproject.org/fedora:26 Fedora 26 image is 4 months old. What are the plans for respining these images on regular basis? Especially the development "releases" tend to change quite heaving and if we do not want to encourage the use of RUN dnf upgrade -y in every Dockerfile, we might want to make it easy for people to consume fresh content. Incidently, registry.fedoraproject.org/fedora:25 is rather new, just 13 days old. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announce: Fedora Layered Image Release
On Fri, Apr 28, 2017 at 09:03:48AM -0500, Adam Miller wrote: > On Fri, Apr 28, 2017 at 2:39 AM, Jan Pazdziora wrote: > > > > If we are building building images > > > > FROM fedora:25 > > > > should we start using > > > > FROM registry.fedoraproject.org/fedora:25 > > > > instead in Dockerfiles? If merely fedora does not point to whatever > > is the authoritative location for Fedora images, shouldn't it be purged > > in docker.io to avoid confusion? > > We do have 'FROM registry.fedoraproject.org/fedora:25' in our > Container Guidelines[0] today. Ah, thank you for pointing that out. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announce: Fedora Layered Image Release
On Thu, Apr 20, 2017 at 10:39:22PM -0500, Adam Miller wrote: > Hello all, > On behalf of the Fedora Atomic WG[0] and Fedora Release > Engineering[1], I am pleased to announce the latest Fedora Layered > Image Release. This follows the latest Atomic Host Release that came > out yesterday[2]. > > At this time the following Container Images are available in the > Fedora Registry. > > Base Images: > > (Note that the "latest" tag currently points to "25" and the "rawhide" > tag currently points to "27", if no tag is provided in your pull > command then it will always default to "latest") > > registry.fedoraproject.org/fedora:latest > registry.fedoraproject.org/fedora:rawhide > registry.fedoraproject.org/fedora:27 > registry.fedoraproject.org/fedora:26 > registry.fedoraproject.org/fedora:25 > registry.fedoraproject.org/fedora:24 What is the relationship to docker.io/fedora? Running docker pull for various images and then docker images, I can see REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/fedora24 f623aaef07f05 months ago204.4 MB registry.fedoraproject.org/fedora 24 f623aaef07f05 months ago204.4 MB so for Fedora 24 the images are the same, but REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/fedora25 15895ef0b3b26 days ago 230.9 MB registry.fedoraproject.org/fedora 25 b414411f6e007 days ago 230.9 MB So it looks like docker.io/fedora has newer Fedora 25 image than registry.fedoraproject.org/fedora. Is that expected? If we are building building images FROM fedora:25 should we start using FROM registry.fedoraproject.org/fedora:25 instead in Dockerfiles? If merely fedora does not point to whatever is the authoritative location for Fedora images, shouldn't it be purged in docker.io to avoid confusion? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: bug - sss default under nsswitch.conf
On Sun, Nov 20, 2016 at 08:59:55PM +0200, Catalin wrote: > the default sss is a good choice for pc into internet without dns settings ? > I saw was reported like a bug > https://bugzilla.redhat.com/show_bug.cgi?id=867473 That bug was resolved. Could you please rephrase your question? Are you not happy with 'sss' being there? Why? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packaging /run/lock/* directories breaks installation in containers
On Mon, Jun 06, 2016 at 11:46:49AM -0500, Rex Dieter wrote: > > Offhand, what seems to be the real problem here is the lack of /run/lock in > the container images. I'd consider that a bug worth fixing. Is that not > possible? I guess it is possible. I just thought the container content is supposed to be minimal on purpose but if the general agreement is that this is a bug and the directori should be there, I sure will file it as a bug against the base image. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: ping spin-kickstarts maintainer (bz1176483)
On Mon, Jun 06, 2016 at 11:23:13AM +0200, Lubomír Sedlář wrote: > Dave Young píše v Po 06. 06. 2016 v 16:56 +0800: > > Hi, > > > > We have a bug report for adding kdump anaconda addon to livecd: > > https://bugzilla.redhat.com/show_bug.cgi?id=1176483 > > > > The bug was created in 2014, seems I can not reach the maintainer. > > What else can I do? Do we have other maintainers for this component? > > Hello, > the kickstarts repo has moved to Pagure recently, so you can open a > pull request: > > https://pagure.io/fedora-kickstarts What is the plan for the 22 active tickets at https://fedorahosted.org/spin-kickstarts/report/1 ? Are reporters expected to recreate them in bugzilla or will they by migrated en masse? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Packaging /run/lock/* directories breaks installation in containers
Hello,
the page
https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
suggests to specify /run/%{name}/ directories and files in %files and
then says
Files placed in the subdirectories may be listed the same way
or omitted entirely as the files will be cleaned up on every
reboot.
I assume it talks about subdirectories of that /run/%{name}/.
However, how about subdirectories like /run/lock/%{name}/ ?
In Fedora base container images, the /run is empty. So when you try to
do
FROM fedora:23
RUN dnf install -y package-which-puts-something-to-run-lock
it will fail because there is no /run/lock there. An example is
opencryptoki and
https://bugzilla.redhat.com/show_bug.cgi?id=1341079
What is the policy about specifying /run/lock/ (and in general
/run/otherdirs/) subdirectories in %files?
Could the guideline be amended to explicitly say that anything under
/run/ which is not under /run/%{name}/ should not be listed in %files?
Thank you,
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[perl-DBD-XBase] Rebase to 1.03.
commit 023bcc6630ac4480b121cf90da53fe6c0fb415d8
Author: Jan Pazdziora
Date: Tue Aug 2 14:50:56 2011 +0200
Rebase to 1.03.
.gitignore |2 +-
DBD-XBase-0.241-dbfdump-rename.patch | 593 --
perl-DBD-XBase.spec | 19 +-
sources |2 +-
4 files changed, 15 insertions(+), 601 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e0ae989..87d6a19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-DBD-XBase-0.241.tar.gz
+DBD-XBase-1.03.tar.gz
diff --git a/perl-DBD-XBase.spec b/perl-DBD-XBase.spec
index fe3aa2a..2805516 100644
--- a/perl-DBD-XBase.spec
+++ b/perl-DBD-XBase.spec
@@ -1,14 +1,13 @@
Name: perl-DBD-XBase
-Version:0.241
-Release:14%{?dist}
+Version:1.03
+Release:1%{?dist}
Summary:Perl module for reading and writing the dbf files
Group: Development/Libraries
License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/DBD-XBase/
-Source0:
http://www.cpan.org/authors/id/J/JA/JANPAZ/DBD-XBase-%{version}.tar.gz
+URL:http://www.adelton.com/perl/DBD-XBase/
+Source0:
http://www.adelton.com/perl/DBD-XBase/DBD-XBase-%{version}.tar.gz
Patch0: DBD-XBase-0.241-indexdump.PL.patch
-Patch1: DBD-XBase-0.241-dbfdump-rename.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
@@ -28,9 +27,14 @@ DBI modules and their man pages.
%prep
%setup -q -n DBD-XBase-%{version}
%patch0 -p1
-%patch1 -p1
chmod a-x eg/*table
+# We want to distribute dbfdump.pl, not dbfdump
+find . -type f | xargs %{__perl} -i.theorig -pe
's/(? - 1.03-1
+- Rebase to 1.03.
+
* Tue Jun 21 2011 Marcela Mašláňová - 0.241-14
- Perl mass rebuild
diff --git a/sources b/sources
index d94aedd..7c159e1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ed36f8722f09406d35c8af801fa78c3b DBD-XBase-0.241.tar.gz
+cbfae03a28dcae0aa0d00bec60ca710d DBD-XBase-1.03.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File DBD-XBase-1.03.tar.gz uploaded to lookaside cache by adelton
A file has been added to the lookaside cache for perl-DBD-XBase: cbfae03a28dcae0aa0d00bec60ca710d DBD-XBase-1.03.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
