Self Introduction: Jun Aruga
Hi, Fedora developers! My name is Jun Aruga. I live in Brno, Czech Republic, working in Red Hat. I mainly have lived in open source world over than 10 years. I worked as a Software Engineer in Japan for a long time, and in Singapore for 3 years. Now I am preparing my first Fedora package for Ruby on Rails 5. Nice to meet you! Best, Jun Aruga -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Self Introductoin: Jun Aruga
Hi, Fedora developers! My name is Jun Aruga. I live in Brno, Czech Republic, working in RedHat. I mainly have lived in open source world over than 10 years. I worked as Software Engineer in Japan for a long time, and in Singapore for 3 years. Now I am preparing my first Fedora package for Ruby on Rails 5. Nice to meet you! Best, Jun Aruga -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaned packages seeking new point of contact
> uglify-js1 (el6) > uglify-js1 (epel7) > uglify-js1 (f23) > uglify-js1 (f24) > uglify-js1 (f25) > uglify-js1 (master) > uglify-js (el6) > uglify-js (epel7) > uglify-js (f23) > uglify-js (f24) > uglify-js (f25) > uglify-js (master) I took uglify-js to fix one issued which was affected on my managed packages. Jun Aruga - Original Message - > From: "Kevin Fenzi" <ke...@scrye.com> > To: devel@lists.fedoraproject.org > Sent: Friday, July 29, 2016 7:21:38 PM > Subject: Orphaned packages seeking new point of contact > > Greetings. > > Per: > > #topic #1602 dvgrab, non-responsive maintainer > .fesco 1602 > https://fedorahosted.org/fesco/ticket/1602 > > #topic #1603 scons, non-responsive maintainer for epel builds > .fesco 1603 > https://fedorahosted.org/fesco/ticket/1603 > > #topic #1604 wise2, non-responsive maintainer > .fesco 1604 > https://fedorahosted.org/fesco/ticket/1604 > > #topic #1607 Orphan package for "patches" > .fesco 1607 > https://fedorahosted.org/fesco/ticket/1607 > > I have orphaned the following packages / branches and they need a new point > of > contact to stay in the Fedora or EPEL Collections: > > ascii (epel7) > ascii (f23) > ascii (f24) > ascii (f25) > ascii (master) > blender (el6) > blender (epel7) > blender (f23) > blender (f24) > blender (f25) > blender (master) > bouncycastle-mail (el5) > bouncycastle-mail (el6) > bouncycastle-mail (epel7) > bouncycastle-tsp (el5) > bouncycastle-tsp (el6) > coffee-script (el6) > coffee-script (epel7) > coffee-script (f23) > coffee-script (f24) > coffee-script (f25) > coffee-script (master) > compat-libuv010 (f23) > compat-libuv010 (f24) > compat-libuv010 (f25) > compat-libuv010 (master) > dom4j (el6) > dvgrab (f23) > dvgrab (f23) > dvgrab (f24) > dvgrab (f24) > dvgrab (f25) > dvgrab (f25) > dvgrab (master) > dvgrab (master) > emacs-common-ess (f23) > emacs-common-ess (f24) > emacs-common-ess (f25) > emacs-common-ess (master) > firecontrol (f23) > firecontrol (f24) > firecontrol (f25) > firecontrol (master) > ghc-editline (f23) > ghc-editline (f24) > ghc-editline (f25) > ghc-editline (master) > ghc-primes (f23) > gnu-smalltalk (el5) > gnu-smalltalk (el6) > gnu-smalltalk (epel7) > gnu-smalltalk (f23) > gnu-smalltalk (f24) > gnu-smalltalk (f25) > gnu-smalltalk (master) > gnustep-back (el6) > gnustep-back (f23) > gnustep-back (f24) > gnustep-back (f25) > gnustep-back (master) > gnustep-base (el6) > gnustep-base (epel7) > gnustep-base (f23) > gnustep-base (f24) > gnustep-base (f25) > gnustep-base (master) > gnustep-examples (el6) > gnustep-examples (f23) > gnustep-examples (f24) > gnustep-examples (f25) > gnustep-examples (master) > gnustep-gui (el6) > gnustep-make (el6) > gnustep-make (epel7) > gnustep-make (f23) > gnustep-make (f24) > gnustep-make (f25) > gnustep-make (master) > gorm (el6) > gorm (f23) > gorm (f24) > gorm (f25) > gorm (master) > gprolog (epel7) > gprolog (f23) > gprolog (f24) > gprolog (f25) > gprolog (master) > gresolver (f23) > gresolver (f24) > gresolver (f25) > gresolver (master) > highlight (el5) > highlight (el6) > highlight (f23) > highlight (f24) > highlight (f25) > highlight (master) > http-parser (el5) > http-parser (el6) > http-parser (epel7) > http-parser (f23) > http-parser (f24) > http-parser (f25) > http-parser (master) > icu4j (el6) > inadyn (el5) > inadyn (el6) > inadyn-mt (f23) > inadyn-mt (f24) > inadyn-mt (f25) > inadyn-mt (master) > jaxen-bootstrap (el6) > js-jquery1 (el5) > js-jquery1 (el6) > js-jquery1 (epel7) > js-jquery1 (f23) > js-jquery1 (f24) > js-jquery1 (f25) > js-jquery1 (master) > js-jquery (el5) > js-jquery (el6) > js-jquery (epel7) > js-jquery (f23) > js-jquery (f24) > js-jquery (f25) > js-jquery (master) > js-jquery-migrate (el5) > js-jquery-migrate (el6) > js-jquery-migrate (epel7) > js-jquery-migrate (f23) > js-jquery-migrate (f24) > js-jquery-migrate (f25) > js-jquery-migrate (master) > js-sizzle (el6) > js-sizzle (epel7) > js-sizzle (f23) > js-sizzle (f24) > js-sizzle (f25) > js-sizzle (master) > kaya (f23) > kaya (f24) > kaya (f25) > kaya (master) > kyum (el5) > kyum (el6) > latex2emf (f23) > latex2emf (f24) > latex2emf (f25) > latex2emf (master) > libart_lgpl (f23) > libart_lgpl (f24) > libart_lgpl (f25) > libart_lgpl (master) > libavc1394 (f23) > libavc1394 (f24) > libavc1394 (f25) > libavc1394 (master) > libdiscid (f23) > libdiscid (f24) > libdiscid (f25
rubygem-thin license change
Hi, rubygem-thin package changes from (GPLv2 or Ruby) and MIT to (GPLv2+ or Ruby) and BSD and MIT Regards, Jun Aruga -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bash style guide on Fedora?
Hi, > I'm not familiar with one, but I'd recommend using shellcheck on them to > detect potential issues. Thanks. shellcheck? you mean "sh -n something.sh"? Yes, I will do it too :) I mean such as following pages, that I just searched on internet. https://google.github.io/styleguide/shell.xml https://github.com/icy/bash-coding-style http://wiki.bash-hackers.org/scripting/style Jun Aruga - Original Message - > From: "Christopher" <ctubb...@fedoraproject.org> > To: "Development discussions related to Fedora" > <devel@lists.fedoraproject.org> > Sent: Monday, August 22, 2016 4:25:16 PM > Subject: Re: bash style guide on Fedora? > > On Mon, Aug 22, 2016 at 10:01 AM Jun Aruga < jar...@redhat.com > wrote: > > > Hi, > > We can see several bash (= sh on Fedora) script files under /etc such as > /etc/init.d/functions > /etc/profile > > Anyone could you tell me whether there is a common style guideline (coding > standards) to write the shell script on Feodra? > > Thanks, > Jun Aruga > > > I'm not familiar with one, but I'd recommend using shellcheck on them to > detect potential issues. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bash style guide on Fedora?
Hi, > You can also take a look at bashate [ https://pypi.python.org/pypi/bashate ], > an automated style checker for bash scripts > to fill the same part of code review that pep8 does in most OpenStack > projects. > Thanks, Its tool looks helpful & useful for me. I would take a look at it. Thanks. Jun Aruga - Original Message - > From: "chandan kumar" <chandankumar.093...@gmail.com> > To: "Development discussions related to Fedora" > <devel@lists.fedoraproject.org> > Sent: Monday, August 22, 2016 4:31:38 PM > Subject: Re: bash style guide on Fedora? > > Hello, > > On Mon, Aug 22, 2016 at 7:55 PM, Christopher < ctubb...@fedoraproject.org > > wrote: > > > > On Mon, Aug 22, 2016 at 10:01 AM Jun Aruga < jar...@redhat.com > wrote: > > > Hi, > > We can see several bash (= sh on Fedora) script files under /etc such as > /etc/init.d/functions > /etc/profile > > Anyone could you tell me whether there is a common style guideline (coding > standards) to write the shell script on Feodra? > > Thanks, > Jun Aruga > > > I'm not familiar with one, but I'd recommend using shellcheck on them to > detect potential issues. > > > You can also take a look at bashate [ https://pypi.python.org/pypi/bashate ], > an automated style checker for bash scripts > to fill the same part of code review that pep8 does in most OpenStack > projects. > Thanks, > > Chandan Kumar > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
bash style guide on Fedora?
Hi, We can see several bash (= sh on Fedora) script files under /etc such as /etc/init.d/functions /etc/profile Anyone could you tell me whether there is a common style guideline (coding standards) to write the shell script on Feodra? Thanks, Jun Aruga -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Flock 2016 Slices & Videos
Hi, For the person who not attend Flock 2016 event. As I knew the useful page for the event today, let me announce you. You can watch videos and slices from following page. Flock 2016 Talks (Slides, Videos) https://fedoraproject.org/wiki/Flock_2016_Talks As the page has links to slides and videos for some, not all talks, if you are the speaker and you have slide or video, I would like you to upload those to the page. Thank you. -- Jun Aruga -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bash style guide on Fedora?
Hi, Okay, I could install the shellcheck with the Fedora package. And it works, and it looks nice. I am going to use those 2 checkers for a while. Thanks. Jun Aruga - Original Message - > From: "Christopher" <ctubb...@fedoraproject.org> > To: "Development discussions related to Fedora" > <devel@lists.fedoraproject.org> > Sent: Monday, August 22, 2016 9:40:25 PM > Subject: Re: bash style guide on Fedora? > > On Mon, Aug 22, 2016 at 11:17 AM Dominique Martinet < > dominique.marti...@cea.fr > wrote: > > > Jun Aruga wrote on Mon, Aug 22, 2016 at 10:36:48AM -0400: > > shellcheck? you mean "sh -n something.sh"? Yes, I will do it too :) > > He does mean shellcheck[1]. > > It's nice; doesn't do style check (e.g. trailing spaces or whatsnot) > but catches quite a lot of errors. > > > [1] https://www.shellcheck.net/ > > Yes, this is the shellcheck[1] I meant, but it's also just packaged for > Fedora: > $ sudo dnf install ShellCheck > $ shellcheck myscript.sh > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Package naming question
Perl: perl-foo Python: python-foo NodeJs (NPM): nodejs-foo Ruby: rubygem-foo R: R-foo PHP: php-foo Golang: golang-foo The prefix pattern "rust-parallel" looks better. Jun On Mon, Dec 4, 2017 at 3:45 PM, Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Mon, Dec 04, 2017 at 09:19:26AM -0500, Gerald Henriksen wrote: > > On Mon, 04 Dec 2017 10:20:13 +0100, you wrote: > > > > >I would like to hear opinion of other packagers about naming. We have > > >`parallel` utility implemented in Rust which is drop-in replacement for > GNU > > >parallel. I was thinking how to name package and how people would > expect it to > > >be named. So far options are: > > > > > >* rust-parallel > > >* parallel-rust > > >* parallel-rs > > > > > >I dislike first one because it is not ending up in completion while > second and > > >third are quite good. > > > > To me the second and third make it look like the package is part of > > the existing parallel package - perhaps rust bindings to parallel - > > and not an entirely different program. > > > > In other words, I could see people install parallel-rust because "it > > must be part of the parallel package" based on its naming and not > > realize it is an entirely different program doing the same thing. > > Yes. In other words, the problem started when somebody decided to > reimplement a well-known existing package in a different language without > changing the name. It seems like the right solution is to ask the > rust-parallel folks to rename their project instead of squatting on an > existing name. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- Jun Aruga jar...@redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Fedora-packaging] Re: Package naming question
Jason, > If you discount the guidelines for multiple parallel-installable > versions of the same package, we don't really have an established naming > convention for alternate versions of a "thing". Thanks for mentioning it and the detailed explanation. I did misunderstand it. I understand what you are talking about. Yeah, the suffix style "parallel-rust" looks better. Jun On Mon, Dec 4, 2017 at 11:10 PM, Jason L Tibbitts III <ti...@math.uh.edu> wrote: > >>>>> "JA" == Jun Aruga <jar...@redhat.com> writes: > > JA> Perl: perl-foo Python: python-foo NodeJs (NPM): nodejs-foo Ruby: > JA> rubygem-foo R: R-foo PHP: php-foo Golang: golang-foo > > Those are all for libraries in the given language. > > JA> The prefix pattern "rust-parallel" looks better. > > This is not a library written in rust. > > https://fedoraproject.org/wiki/Packaging:Guidelines# > Library_or_Application.3F > > If you discount the guidelines for multiple parallel-installable > versions of the same package, we don't really have an established naming > convention for alternate versions of a "thing". Best I can think of are > things like libart_lgpl (which doesn't and maybe never did have a > non-lgpl version), reentrant versions of libraries like libqhull_r > (which has the least useful package %description I've ever seen), though > those aren't generally packaged separately, or, I don't know, > chromium-libs-media-freeworld (which I know isn't a Fedora package). > > Honestly I'd just pretend that what you have really _is_ a different > version of the same package, but instead of being version '3', it's > version 'rust'. And for that we have > https://fedoraproject.org/wiki/Packaging:Naming# > Multiple_packages_with_the_same_base_name > which would suggest "parallel-rust". > > For the actual executables, we have a long tradition of prefixing 'k' > for kerberized versions of things, and postfixing version numbers, > sometimes with dashes. Which really doesn't clarify much of anything. > About all we can say with certainty is that this package can't install > /usr/bin/parallel. > > - J< > -- Jun Aruga jar...@redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Rawhide / ruby / SystemStackError / "stack level too deep"
> If anyone notices Ruby programs which suddenly start to throw stack overflow errors (SystemStackError or the error message "stack level too deep") but *only* in the latest Rawhide (glibc >= 2.26-9000, ruby >= 2.5.0), then I'm interested to hear from you. I faced "stack level too deep" when running a unit test for rubygem-mysql2. As when I ran the case's logic it manually, that was okay, I just commented out the test case. https://src.fedoraproject.org/rpms/rubygem-mysql2/blob/master/f/rubygem-mysql2.spec#_154 https://github.com/rails/rails/blob/v5.0.0/activesupport/CHANGELOG.md stack level too deep error Jun On Thu, Jan 11, 2018 at 3:10 PM, Richard W.M. Jones <rjo...@redhat.com> wrote: > > OK I believe this is actually a bug in the nbdkit plugin rather than > glibc / Ruby. Apparently you need to call some functions to tell Ruby > about the thread stacks. Totally undocumented ... > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Jun Aruga jar...@redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
rubygem-coderay license change
License of rubygem-coderay package was changed from: LGPLv2+ to: MIT https://src.fedoraproject.org/rpms/rubygem-coderay/c/24c8b248c94fb8f0c4173e59bc8eb17f291c767e?branch=master -- Jun Aruga jar...@redhat.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_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6DZSKB2HZ6IZLGXOFJ7357RHF3X5IH26/
Re: python-pip license changed (and clarified)
9.0.x -> 10.0.x then 18.0? > https://github.com/pypa/pip/blob/master/NEWS.rst > Switch to a Calendar based versioning scheme. Oh they changed the versioning rule. Jun On Tue, Jul 31, 2018 at 3:48 PM, Miro Hrončok wrote: > python-pip 9.0.x had MIT as License (bundled deps were not mentioned) > > python-pip 18.0 now has more enjoyable: > > MIT and Python and ASL 2.0 and BSD and ISC and LGPLv2 and MPLv2.0 and (ASL > 2.0 or BSD) > > License breakdown is in the specfile. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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/HQWC4L7UKBVWSCSL33WM5P5QN6HTZB2U/ -- Jun Aruga jar...@redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic ___ 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/ONCVQOWEI7CMHT4CHMCCZXZGADM3HWMW/
Re: Release rpkg-1.56 and fedpkg-1.35
> rpkg: https://docs.pagure.org/rpkg/releases/1.56.html > Greenwave policy could be validated when build a package with build command, > or a container with container-build command, if policy file gating.yaml is > created in the root directory inside repostiory. If the policy is valid, > build will be proceeded, otherwise, packagers have to fix it. It looks cool new feature of Greenwave [1]. Thanks. In my impression, we have several CIs, Greenwave, Fedora CI, testing framework for modularity on Fedora Project. [1] https://docs.pagure.org/greenwave/policies.html Jun On Wed, Aug 22, 2018 at 9:22 AM, Chenxiong Qi wrote: > Hi, > > New version rpkg-1.56 and fedpkg-1.35 are released. > > Release notes: > > * rpkg: https://docs.pagure.org/rpkg/releases/1.56.html > * fedpkg: https://docs.pagure.org/fedpkg/releases/1.35.html > > Bodhi updates: > > https://bodhi.fedoraproject.org/updates/rpkg-1.56-1.fc28%20fedpkg-1.35-1.fc28 > https://bodhi.fedoraproject.org/updates/rpkg-1.56-1.fc27%20fedpkg-1.35-1.fc27 > https://bodhi.fedoraproject.org/updates/rpkg-1.56-1.el6%20fedpkg-1.35-1.el6 > https://bodhi.fedoraproject.org/updates/rpkg-1.56-1.el7%20fedpkg-1.35-1.el7 > > Regards, > Chenxiong Qi > > ___ > 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/WH7TMHJ565ETG2OSG5VRUO5NOBW3VXYO/ -- Jun Aruga jar...@redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic ___ 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/W2I4IIVJOHTH7IGJXHSNI3EUWW6377OD/
[modularity] Recommended platform: [] and version 2 format
Just sharing information. When talking with a person in modularity team, I have told that for a module config yaml file's below elements, the empty array "[]" was recommended on Fedora. /data/dependencies/buildrequires/platform /data/dependencies/requires/platform Because when platform is "[]", the module is built on current supported platforms (right now f28, f29, and f30). The binary of the module are prepared for each platform. I hope the document is updated including this recommended setting as a best practice. ``` diff --git a/ruby.yaml b/ruby.yaml tracker: https://bugs.ruby-lang.org/ dependencies: - buildrequires: -platform: [f29] +platform: [] requires: -platform: [f29] +platform: [] components: # SRPMs rpms: ``` Also seeing several modules' config YAML files, some config files are still version 1. I like to share that we can use the version 2, changing the /version element from 1 to 2. Version 2 spec: https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml Regards, -- Jun Aruga jar...@redhat.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_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upstream tip wanted: CI service for Big Endian acrhes
I just created the topic on Travis community page. https://travis-ci.community/t/multiarch-testing-tips/862 Jun ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upstream tip wanted: CI service for Big Endian acrhes
Travis Ci (or any CI) + multiarch (QEMU) project + Big-endian arch enables testing on big-endian arch. As far as I know, this is the easiest way to test big-endian on the CI. ``` $ docker run --rm --privileged multiarch/qemu-user-static:register --reset $ docker run --rm -t multiarch/fedora:25-ppc64 uname -a Linux 870bdcfe1bff 4.16.15-300.fc28.x86_64 #1 SMP Tue Jun 12 00:42:35 UTC 2018 ppc64 ppc64 ppc64 GNU/Linux $ docker run --rm -t multiarch/debian-debootstrap:s390x-jessie uname -a Linux e774bfd6a08e 4.13.0-1008-gcp #11-Ubuntu SMP Thu Jan 25 11:08:44 UTC 2018 s390x GNU/Linux ``` See also my experiment for the topic: https://github.com/junaruga/ci-multi-arch-test https://github.com/junaruga/ci-multi-arch-test/blob/master/.travis.yml Maybe below mutlarch container images for Fedora and CentOS could be maintained with better way and newer version. multiarch Fedora: https://hub.docker.com/r/multiarch/fedora/tags/ multiarch CentOS: https://hub.docker.com/r/multiarch/centos/tags/ Jun On Mon, Nov 12, 2018 at 5:09 PM, Brian Stinson wrote: > On Nov 12 13:32, Miro Hrončok wrote: >> Recently I've reported some Big Endian related test failures to an upstream >> project [0]. >> >> I was asked by an upstream project maintainer, whether I know some free >> Continuous Integration services where they can easily run their testsuite on >> Big Endian. >> >> Any tips? >> >> * Upstream uses Travis CI to test on x86_64 Linux (Ubuntu) >> * Upstream uses AppVeyor to test on Microsoft Windows >> * It's a pure Python project, noarch, but some changes need to be done when >> loading/saving binary data (LE) with NumPy on BE system. >> >> What I've considered: >> >> * COPR (but there is no big endian arch) >> * (Ab)using Koji (I guess that would be considered a bad practice?) >> * using QUEMU on Travis CI [1] >> >> Any better tips? Thanks >> >> [0] https://github.com/mikedh/trimesh/issues/249 >> [1] >> https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architecture-ci-workflow/ >> >> -- >> Miro Hrončok >> -- >> Phone: +420777974800 >> IRC: mhroncok >> ___ >> 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 > > This may not be helpful if you need to target S390x specifically, but we > have PPC Big-endian CentOS VMs for projects in CentOS CI: > > https://wiki.centos.org/QaWiki/CI/Multiarch > > I'm happy to chat with you and your upstream about providing some > resources here. > > -- > Brian Stinson > CentOS CI Infrastructure Team > ___ > 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 -- Jun Aruga jar...@redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic ___ 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] Recommended platform: [] and version 2 format
Thanks for explaining about it! I found the part of "platform: []" in the document you shared. https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/#_modular_dependencies Jun On Wed, Sep 12, 2018 at 11:07 AM, Adam Samalik wrote: > That's right! > > This and more is documented in the Modularity section of Fedora Docs: > https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/ > > On Wed, Sep 12, 2018 at 10:56 AM Jun Aruga wrote: >> >> Just sharing information. >> >> When talking with a person in modularity team, I have told that for a >> module config yaml file's below elements, the empty array "[]" was >> recommended on Fedora. >> >> /data/dependencies/buildrequires/platform >> /data/dependencies/requires/platform >> >> Because when platform is "[]", the module is built on current >> supported platforms (right now f28, f29, and f30). The binary of the >> module are prepared for each platform. >> I hope the document is updated including this recommended setting as a >> best practice. >> >> ``` >> diff --git a/ruby.yaml b/ruby.yaml >> tracker: https://bugs.ruby-lang.org/ >> dependencies: >> - buildrequires: >> -platform: [f29] >> +platform: [] >>requires: >> -platform: [f29] >> +platform: [] >> components: >> # SRPMs >> rpms: >> ``` >> >> Also seeing several modules' config YAML files, some config files are >> still version 1. >> I like to share that we can use the version 2, changing the /version >> element from 1 to 2. >> >> Version 2 spec: >> https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml >> >> Regards, >> >> -- >> Jun Aruga jar...@redhat.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_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > -- > > Adam Šamalík > --- > 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 > -- Jun Aruga jar...@redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic ___ 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
Module's package branch name to be aligned?
Hi, I like to see "package branch name" of each modules to be aligned more. Here is a list of the current module, the module stream name, the package branch name, another package name. There are some patterns on the list. # module, the module stream name (module/foo's branch), the package branch name (rpms/foo's branch), another package name (rpms/bar's branch) mongodb3.6 3.6 None nodejs8 8 None perl5.24 fXX fXX python3 3.6 None None python36 3.6 None master ruby 2.5 ruby-2.5 master scala 2.10 javapackages javapackages varnish 6 stream-6 stream-6 See more detail at https://pagure.io/jaruga-modules-branches I think "None" is same with "master" technically. In case of modules/ruby, we ruby team decided "the package branch name" as "ruby-X.Y" with a module name prefix against "X.Y" documented in the naming guideline. Because a package of a module A (ex. modules/ruby) can be used also in a module B (ex. modules/rubygem-rails, modules/vagrant and etc. In this case, a package branch name needs to have "ruby-X.Y", "rubygem-rails-X.Y", "vargrant-X.Y". Do you like to see some alignments for the naming? Hopefully after the discussion here in this thread, below page will be updated. https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/#_package_branch_name Regards, Jun ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Module's package branch name to be aligned?
On Tue, Apr 16, 2019 at 3:38 PM Igor Gnatenko wrote: > > Why? > > What is the problem with packages having branch "latest", "1.x" and such? It's no problem. Rather it might be better in the point of view of "minimal necessary package branches for now". I thought it again. I considered below case of that a package is included in 2 different modules. Then in the case, a module bar can not refer rpms/bar's 1.2 branch because of specific issue of module bar. But creating new branch "bar-1.2" on rpms/foo on that time might solve the situation. On modules/foo branch: 1.2 foo.yml data: components: foo: ref: 1.2 On modules/bar branch: 3.4 bar.yml data: components: foo: ref: bar-1.2 rpms/foo branch: 1.2 branch: bar-1.2 -- Jun ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Module's package branch name to be aligned?
Hi Mikolaj
> I thought of using names in format "stream-${name}-${stream}" (eg.
stream-scala-2.10), but I can use "${name}-${stream}" (scala-2.10)
format too - consistency between modules is more important than
maintainer personal preferences.
I just checked current modules' situation in f29 module repository.
Maybe this list shows all the module or most modules in it.
The result is here.
https://pagure.io/jaruga-modules-branches
So, current package branch name patterns are
* "stream-${name}-${stream}": 2 (postgresql, varnish)
* "${name}-${stream}": 1 (ruby (but not created yet))
* Both "${name}-${stream}" and "${stream}": 1 (kubernetes)
* "${stream}": 11
Remarkable case is kubernetes module.
2 types of module stream names: 1.10, openshift-3.10
2 types of package branch names: 1.10, openshift-3.10
1.10 is maybe used like a kubernetes-1.10 branch.
There is no "${name}-${stream}" except ruby I thought I would create it.
As the examples of package branch names are defined explicitly
referring http://calver.org/ .
https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/#_package_branch_name
In the point of consistency of "current" modules, it might be better
to align with a kubernetes module's style.
That is
* As a first branch name: "${stream}"
* As a 2nd branch name: foo-${stream}
Jun
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity tooling intro?
Maybe this is the document.
https://docs.fedoraproject.org/en-US/modularity/making-modules/
In my understanding below command executes "mbs-manager" internally.
I do not run "mbs-manager" command directly.
```
$ fedpkg module-build
```
On Thu, May 30, 2019 at 11:17 AM Paul Howarth wrote:
>
> Hi everyone,
>
> I have a bunch of packages in a local repo built for various versions
> of Fedora and CentOS, and am looking to build some of them for EL-8.
> Clearly the way to go for an EL-8 add-on repo is to build modules, so
> that it what I'd like to do. However, I want to do it on my own
> infrastructure and hence use the lower-level tooling such as
> mbs-manager/mock and local git repos rather than fedpkg/koji/dist-git.
>
> There's quite a bit of documentation around about building modules but
> what I've found seems to be either out of date (e.g. uses "mbs-build",
> which no longer exists) or is based on fedpkg, which abstracts away the
> lower-level operation and is geared towards Fedora infrastructure.
>
> Is there some documentation somewhere that covers getting started with
> the tools like mbs-manager?
>
> I thought this workshop looked like a good starting point:
> https://github.com/fedora-modularity/workshop
>
> When I discovered that "mbs-build" no longer exists, I tried using
> "mbs-manager" but clearly I'm missing something:
>
> $ mbs-manager build_module_locally --file test-module.yaml -s platform:f30
> 2019-05-30 09:51:04,712 - MainThread - urllib3.util.retry - DEBUG - Converted
> retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=None,
> status=None)
> 2019-05-30 09:51:04,863 - MainThread - moksha.hub - WARNING - Cannot find
> qpid python module. Make sure you have python-qpid installed.
> 2019-05-30 09:51:05,577 - MainThread - MBS.utils.submit - DEBUG - Submitted
> normal module build for test-module:f30:20190530085105
> Traceback (most recent call last):
> File "/usr/bin/mbs-manager", line 11, in
> load_entry_point('module-build-service==2.19.1', 'console_scripts',
> 'mbs-manager')()
> File "/usr/lib/python3.7/site-packages/module_build_service/manage.py",
> line 251, in manager_wrapper
> manager.run()
> File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 417,
> in run
> result = self.handle(argv[0], argv[1:])
> File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 386,
> in handle
> res = handle(*args, **config)
> File "/usr/lib/python3.7/site-packages/flask_script/commands.py", line 216,
> in __call__
> return self.run(*args, **kwargs)
> File "/usr/lib/python3.7/site-packages/module_build_service/manage.py",
> line 167, in build_module_locally
> username, handle, params, stream=str(stream), skiptests=skiptests)
> File
> "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py", line
> 503, in submit_module_build_from_yaml
> return submit_module_build(username, mmd, params)
> File
> "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py", line
> 633, in submit_module_build
> mmds = generate_expanded_mmds(db.session, mmd, raise_if_stream_ambigous,
> default_streams)
> File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py",
> line 417, in generate_expanded_mmds
> current_mmd = Modulemd.Module.new_from_string(mmd.dumps())
> TypeError: :
> Argument 0 does not allow None as a value
>
> Any pointers anyone?
>
> Paul.
> ___
> 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
--
Jun Aruga / He - His - Him
jar...@redhat.com / IRC: jaruga
___
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 tooling intro?
> However, I want to do it on my own infrastructure and hence use the lower-level tooling such as mbs-manager/mock and local git repos rather than fedpkg/koji/dist-git. Sorry I missed your above message. Maybe you can open the ticket at below repository's issue page. https://pagure.io/fm-orchestrator fm-orchestrator repository is including module-build-service, and mbs-manager. I remember "mbs-build local" command worked for the local build in late 2017. But I could not find the command now. -- Jun Aruga / He - His - Him ___ 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: Where are armv7hl, i686 and ppc64le Container tar.xz files?
Kevin and Clement, thanks for the explanation. I am looking forward to seeing the final compose. > So, likely we haven't had a armv7 fedora 30 compose recently, and so no one has updated it. The container sig would be the ones to ask here. Sure, I will subscribe the mailing list. > Yes I do the Dockerhub updates, and since we did not have a full compose working in a while I did my best to at least get something out for fedora 30. Thank you for your work! I appreciate it. > The problem we have with the compose is tracked in this ticket --> https://pagure.io/releng/issue/8173 Sure, I will subscribe it. By the way, let me tell you why I want the mult arch Container. I am working for multiarch project now [1]. As you may know, when we build or run different arch container (ex. aarch64) on the host arch (ex. x86_64), we can not do it. ``` $ docker run --rm -t arm64v8/fedora:30 uname -m standard_init_linux.go:207: exec user process caused "no such file or directory" ``` But below commands should work on your x86_64 host OS. As it is not officially released on the multiarch project, it is still my private container repository. $ docker run --rm --privileged multiarch/qemu-user-static:register --reset $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-aarch64 uname -m aarch64 $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-s390x uname -m s390x This technology enables you to debug your app on the multi arch environment on local easily or add the environment to your x86_64 base CI. If you are interested in how it works, see [2] and [3]. [1] multiarch project: https://github.com/multiarch [2] https://github.com/multiarch/qemu-user-static [3] https://github.com/multiarch/fedora -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ 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: Docker and user namespaces on F30
> On Mon, May 06, 2019 at 04:17:18PM +0200, Jun Aruga wrote: > > Podman 1.2 and Docker CE 18.09.5 on My Fedora 30 work for your use case. > > > > $ docker --version > > Docker version 18.09.5, build e8ff056 > > This is not what Fedora ships. We have (in F30) > docker-1.13.1-67.git1185cfd or moby-engine-18.06.3-2.ce.gitd7080c1. Yes, it's not what Fedora ships, because I wanted to use below feature in my use cases. The docker Fedora ships does not have the feature, but podman has it. https://github.com/moby/moby/blob/master/CHANGELOG.md > 17.05.0-ce (2017-05-04) > Allow using build-time args (ARG) in FROM #31352 The rpms/docker will be removed on F31. I guess after F31, rpms/podman's poman-docker is the new one for the docker command. https://src.fedoraproject.org/rpms/docker/tree/master https://src.fedoraproject.org/rpms/podman/blob/master/f/podman.spec#_520 I use both Podman and Docker CE to check compatibilitiies between them and check Docker CE's new features, reporting it to podman GitHub for contributions. I think that it's beneficial that someone does this to know the trend, not to be isolated from the market's needs. > What is going on with this very weird, very confusing versioning? The Fedora version doesn't even look like the upstream date-based version numbers? Is the Fedora release really just that old? Yes, the Fedora release is old. Though I might be wrong, It's because I suppose that docker changed the versioning and lisence policy at the point of the past time. Fedora can not ship it because of that. After F31, you do not see the confusing versioning, because podman-docker is shipped instead of docker. -- Jun Aruga / He - His - Him ___ 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: Where are armv7hl, i686 and ppc64le Container tar.xz files?
I am suggesting a new feature "podman buildx" like "docker buildx" that makes a better multi arch build experience. See below URL if you are interested in it. Supporting building multi-platform images (podman buildx) https://github.com/containers/buildah/issues/1590 -- Jun Aruga / He - His - Him ___ 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: Docker and user namespaces on F30
> Which looks even stranger. > > I see we don't have the same version of docker. I have version 18.06.3, > build d7080c1. Did you install docker from > https://docs.docker.com/install/ ? Yes, for docker-ce I installed it from the page's Linux/Fedora page when I used Fedora 29. If you are fine to remove all the images, try below one. $ sudo systemctl stop docker $ cd /var/lib/ $ sudo rm -rf docker $ sudo systemctl start docker <= recreate initial /var/lib/docker $ docker run -it --rm docker.io/php:7-fpm-alpine sh For podman, if you have not set the rootless setting to run podman without sudo, you can try it with sudo. $ sudo podman run -it --rm docker.io/php:7-fpm-alpine sh Does below command work for you? $ docker run -t --rm docker.io/alpine uname -a Linux 828dcafd0bbe 5.0.10-300.fc30.x86_64 #1 SMP Tue Apr 30 16:22:12 UTC 2019 x86_64 Linux > However, dk run --userns=host -it --rm docker.io/php:7-fpm-alpine sh > works fine. So it seems to be limited to user namespaces. What is dk command? -- Jun Aruga / He - His - Him ___ 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: Where are armv7hl, i686 and ppc64le Container tar.xz files?
> > ``` > > $ docker run --rm -t arm64v8/fedora:30 uname -m > > standard_init_linux.go:207: exec user process caused "no such file or > > directory" > > ``` > > you should just run > $ docker run --rm -t fedora:30 uname -m > on all arches, we push manifest listed containers to dockerhub so that > command will work everywhere. Alright, I did not know the kind of alias feature. Thanks for the info. -- Jun Aruga / He - His - Him ___ 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: Where are armv7hl, i686 and ppc64le Container tar.xz files?
> > you should just run > > $ docker run --rm -t fedora:30 uname -m > > on all arches, we push manifest listed containers to dockerhub so that > > command will work everywhere. > > Alright, I did not know the kind of alias feature. Thanks for the info. But my motivation is not like * Running x86_64 container on x86_64 machine * Running aarch64 container on aarch64 machine ... but * Running aarch64, s390x, ppc64le and etc containers on x86_64 machine. The reason is that makes multi arch's tests enable on x86_64 environment or x86_64 base CI service. -- Jun Aruga / He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Module's package branch name to be aligned?
Modularity team, On below definition of the modularity document, there is a problem, as Vit said. https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/#_package_branch_name The problem is If we use X.Y.Z as a package branch name with rpms/bar, for example the situation is like this. modules/foo 2.5 rpms/foo 2.5 rpms/bar 2.5 In this case, seeing rpms/bar 2.5 branch, people tend to recognize it, "bar"'s 2.5 branch. But it's wrong. It can be actually bar 1.2.3 that is included in module foo 2.5. rpms/bar's situation means "rpms/ package branch" in the list. You see several patterns in it. Maybe I covered most modules situation. https://pagure.io/jaruga-modules-branches postgresql module solves the situation like this. modules/foo 11 rpms/foo stream-postgresql-11 rpms/bar stream-postgresql-11 reviewboard module solves the situation like this. modules/foo 3.0 rpms/foo 3.0 rpms/bar 1.2 (it means bar 1.2 version's branch) I wish at least recommended way is documented in the modularity section of the page. -- Jun ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?
I change my question. Do you know who is creating this kind of multi arch container images? https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/aarch64/images/ Jun ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?
I found Fedora 30 armhfp container image here. https://dl.fedoraproject.org/pub/fedora/linux/development/30/Container/ I am still looking for Fedora 30 armv7hl, i686 and ppc64le container images. -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ 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: Where are armv7hl, i686 and ppc64le Container tar.xz files?
> > And why below s390x does not have Fedora-Container-Base-*.tar.xz? > > Those are things that failed in the final RC2 compose of Fedora30. > > Since they were not release blocking, they... didn't block the release. > > ...snip... > > > > I change my question. > > Do you know who is creating this kind of multi arch container images? > > https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/aarch64/images/ > > Those were all made by the Fedora 30 rc2 compose. > > pungi is the tool, and this: > https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf > was the config used. > > Does that answer the question? Yes, Kevin. Thank you for the info. What I do not understand is below DockerHub has Feodra 30 ppc64le, Fedora 29 armhfp that Fedora Project did not release. https://hub.docker.com/r/ppc64le/fedora/ Fedora 29, 30 https://hub.docker.com/r/arm32v7/fedora/ Fedora 29 (not 30) Anyway, as what I wanted is layer.tar in the image archive, maybe I will take it from DockerHub's image like this. $ docker pull arm32v7/fedora:29 $ docker save arm32v7/fedora:29 -o 29-armhfp.tar $ tar -xf 29-armhfp.tar $ ls -l */layer.tar -rw-r--r-- 1 jaruga jaruga 256970240 Feb 20 14:00 88edf58c1d5b3ee606b724b19ac4b4866b20ba93d15d5b330fc6cc29055b480b/layer.tar Thanks. Solved. -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: module testing files?
I think the people who are using or used "meta-test-family" (the application to test module), has these kind of testing files. But I faced an installation error on my Fedora 30. https://github.com/fedora-modularity/meta-test-family/issues/245 Are you using "meta-test-family" now? Does it work on your environment? -- Jun Aruga / He - His - Him ___ 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: [Fedocal] Reminder meeting : Modularity Team (weekly)
> The agenda for the meeting is available as flagged tickets [in the Modularity > repository](https://pagure.io/modularity/issues?status=Open=Meeting). No agenda? I have several topics to let you discuss. -- Jun Aruga / He - His - Him ___ 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: Where are armv7hl, i686 and ppc64le Container tar.xz files?
> pungi is the tool, and this: > https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf > was the config used. Kevin, I have a question. https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf#_322 > 'arches': ['armhfp', 'aarch64', 'ppc64le', 's390x', 'x86_64'], From above setting for Container, ideally those 5 archs should be released on URL [a] or [b]? Where is ppc64le's image? "'distro': 'Fedora-22', " in https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf#_320 is right setting? a. https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/ aarch64, x86_64 b. https://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Container/ s390x c. https://dl.fedoraproject.org/pub/fedora/linux/development/30/Container/ aarch64, armhfp, x86_64 -- Jun Aruga / He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning rubygem-paranoia
Thanks for the action, Vit. I take care for next time. -- Jun Aruga / He - His - Him ___ 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
Orphaning rubygem-paranoia
We have orphaned rubygem-paranoia discussing co-maintainer, as It is not a required package to install Rails. https://bugzilla.redhat.com/show_bug.cgi?id=1675942#c7 -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ 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
Where are armv7hl, i686 and ppc64le Container tar.xz files?
I am looking for arch container archive files like "Fedora-Container-Base-30-1.2.aarch64.tar.xz " for Fedora 30. I found the x86_64, aarch64 and s390x's archive files in below directory. But where is the archive file of armv7hl, i686 and ppc64le? I assume the multi archs except x86_64, aarch64 and s390x existed in the age of Fedora 24, 25 in below releases directory. And why below s390x does not have Fedora-Container-Base-*.tar.xz? https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/ x86_64/ images/ Fedora-Container-Base-30-1.2.x86_64.tar.xz Fedora-Container-Minimal-Base-30-1.2.x86_64.tar.xz aarch64/ images/ Fedora-Container-Base-30-1.2.aarch64.tar.xz Fedora-Container-Minimal-Base-30-1.2.aarch64.tar.xz https://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Container/ s390x/ images/ Fedora-Container-Minimal-Base-30-1.2.s390x.tar.xz => No Fedora-Container-Base-*.tar.xz Thanks. -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ 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: Docker and user namespaces on F30
Podman 1.2 and Docker CE 18.09.5 on My Fedora 30 work for your use case. $ rpm -q kernel kernel-5.0.5-200.fc29.x86_64 kernel-5.0.10-200.fc29.x86_64 kernel-5.0.10-300.fc30.x86_64 $ podman --version podman version 1.2.0 $ podman run -it --rm docker.io/php:7-fpm-alpine sh /var/www/html # uname -a Linux f8b9dafd7816 5.0.10-300.fc30.x86_64 #1 SMP Tue Apr 30 16:22:12 UTC 2019 x86_64 Linux $ docker --version Docker version 18.09.5, build e8ff056 $ docker run -it --rm docker.io/php:7-fpm-alpine sh /var/www/html # uname -a Linux 936e897b0a9b 5.0.10-300.fc30.x86_64 #1 SMP Tue Apr 30 16:22:12 UTC 2019 x86_64 Linux On Sat, May 4, 2019 at 5:05 PM Julien Enselme wrote: > > Hi, > > I just updated to F30 and my docker setup with user namespaces doesn't > work anymore. When I try to run: > docker run -it --rm docker.io/php:7-fpm-alpine sh > I get this error: > docker: Error response from daemon: OCI runtime create failed: > container_linux.go:348: starting container process caused > "process_linux.go:402: container init caused \"rootfs_linux.go:58: > mounting \\\"mqueue\\\" to rootfs > \\\"/var/lib/docker/1000.1001/btrfs/subvolumes/38ce5c87e31bbbcec010db85 > 383d1af57e8652ff4e4c411cebe0c2102a36a020\\\" at \\\"/dev/mqueue\\\" > caused \\\"operation not permitted\\\"\"": unknown. > > I tried to disable SELinux with setenforce 0 but got the same result. > > However, dk run --userns=host -it --rm docker.io/php:7-fpm-alpine sh > works fine. So it seems to be limited to user namespaces. > > My kernel: 5.0.9-301.fc30.x86_64 > > Any ideas on where this may come from? This worked fine on F29 (and > probably on older versions too, I have this setup for a while now). > > Regards, > -- > Julien Enselme > http://www.jujens.eu/ > ___ > 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 -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ 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
module testing files?
Seeing current modules/* 's files. Some of the modules have testing files in the directory. Are the testing files still actually used for the modules? I assume that only modules/foo/foo.yaml file is required. Other files like "sources" are meaningless, right? I think "sources" file is wrongly there. I just checked my local downloaded modules/* directories. $ ls */Dockerfile memcached/Dockerfile mongodb/Dockerfile php/Dockerfile ruby/Dockerfile $ ls */Makefile flatpak-runtime/Makefile memcached/Makefile mongodb/Makefile php/Makefile platform/Makefile ruby/Makefile $ ls -d */tests memcached/tests/ mongodb/tests/ php/tests/ ruby/tests/ $ ls -d */sources eog/sources mariadb/sourcesmongodb/sources perl/sources platform/sourcespython2/sources ruby/sources flatpak-runtime/sources memcached/sources nodejs/sources php/sources postgresql/sources python3/sources varnish/sources I like to see the file structure and testing module is documented or linked in below page https://docs.fedoraproject.org/en-US/modularity/making-modules/ -- Jun Aruga jar...@redhat.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_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Bundler 2.0
There are 2 Ruby modules 2.5 and 2.6. Ruby 2.5 module has rubygem-bundler in it. How about keeping the rubygem-bundler as 1.X? -- Jun Aruga | He - His - Him ___ 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: What other external trackers would you like added to Bugzilla?
For someone who wants to see current registered external bug trackers, click "Add link" drop down list from below link to see the list. :) It's interesting to see many bug trackers are already in it. https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora -- Jun Aruga | He - His - Him ___ 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: Join the new Minimization Team
I also want to join! -- Jun Aruga | He - His - Him ___ 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: Where are armv7hl, i686 and ppc64le Container tar.xz files?
> > Please come! > > > Would love to see your examples use podman... Sorry here is the podman's example. And no worry. podman's examples are used as much as possible in my talk! ``` $ uname -m x86_64 $ podman run --rm -t arm64v8/fedora:30 uname -m standard_init_linux.go:211: exec user process caused "exec format error" $ sudo podman run --rm --privileged multiarch/qemu-user-static --reset -p yes $ podman run --rm -t arm64v8/fedora:30 uname -m aarch64 ``` -- Jun Aruga | He - His - Him ___ 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: Where are armv7hl, i686 and ppc64le Container tar.xz files?
> ``` > $ docker run --rm -t arm64v8/fedora:30 uname -m standard_init_linux.go:207: exec user process caused "no such file or directory" > > $ docker run --rm --privileged multiarch/qemu-user-static:register --reset > $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-aarch64 uname -m > aarch64 Recently our multiarch project released a new feature to enable to run a standard multi-architecture containers on x86_64, without multiarch/* container that was needed before, not depending on host OS environment. That means below workflow works ``` $ uname -m x86_64 $ docker run --rm -t arm64v8/ubuntu uname -m standard_init_linux.go:211: exec user process caused "exec format error" $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes $ docker run --rm -t arm64v8/fedora:30 uname -m aarch64 ``` Is it fine to advertise my talk at Flock 2019 this Friday here? :) Title: Let's add Fedora multiarch containers to your CI. https://flock2019.sched.com/event/SJLx/lets-add-fedora-multiarch-containers-to-your-ci * When: Friday August 9, 2019 10:30 - 10:55 * Where: the room Panorama (140m² / 40 people), The Danubius Hotel HELIA in Budapest, Hungary, at Flock Budapest 2019 = Table of contents = (it might be changed a little bit later) * Fedora and Upstream - Past and Present * CPU Architecture Kinds * Tools for multiarch - Today's topics * QEMU and binfmt_misc - on News * 5 steps - to add Fedora multiarch to upstream CI * 1. qemu-$arch-static - An interpreter * 2. binfmt_misc - A kernel feature for binary format * 3. qemu-user-static RPM on Fedora * 4. qemu-user-static RPM and container * 5. multiarch/qemu-user-static image and CI * Note A: ARM supported CI services * Note B: A Dockerfile to multi-arch images docker buildx, docker/(podman) build --platform Please come! -- Jun Aruga | He - His - Him ___ 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: ownership of /proc and /sys
> I have bunch of ideas, but all of them ugly (e.g., not own that file and > create that directories in scriptlet). Do you > have any ideas about this situation? Make systemd create them? It has to manage them anyway. On Tue, Jul 23, 2019 at 5:30 PM Lennart Poettering wrote: > > On Di, 23.07.19 10:56, Adam Jackson (a...@redhat.com) wrote: > > > On Tue, 2019-07-23 at 11:01 +0200, Miroslav Suchý wrote: > > > Hi, > > > directories /proc/ and /sys/ are owned by filesystem package. This worked > > > in past where we needed those directories to > > > exist so we can mount the procfs and sysfs. > > > > > > However this cause issues in containers: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1548403 > > > and during building where hacks are needed: > > > https://github.com/rpm-software-management/mock/pull/234/commits/d7e0b413c83bec00fd1ed75ee15122a9cc6db62e > > > > > > I have bunch of ideas, but all of them ugly (e.g., not own that file and > > > create that directories in scriptlet). Do you > > > have any ideas about this situation? > > > > Make systemd create them? It has to manage them anyway. > > It does, if they are missing. In fact, it's totally supported to boot > up with an empty / (for example: tmpfs, which is what > systemd.volatile=yes on the kernel cmdline will do) with the one > exception of a populated /usr and systemd will create all the basic > mount points and symlinks needed to make the system boot. > > That said, that only works if / is writable. Which is not a given. > > Lennart > > -- > Lennart Poettering, Berlin > ___ > 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 -- Jun Aruga | He - His - Him jar...@redhat.com / IRC: jaruga ___ 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: ownership of /proc and /sys
Sorry I posted my previous email wrongly. > > I have bunch of ideas, but all of them ugly (e.g., not own that file and > > create that directories in scriptlet). Do you > > have any ideas about this situation? > > Make systemd create them? It has to manage them anyway. I see this situation to think about the ownership of /proc happens when qemu-user-static RPM creates new /proc/sys/fs/binfmt_misc/qemu-$cpu files by "dnf install qemu-user-static" through running systemd. [1] Who is the owner of the /proc/sys/fs/binfmt_misc/qemu-$cpu files? The possible solution I am considering is "(e.g., not own that file and create that directories in scriptlet)". [1] https://bugzilla.redhat.com/show_bug.cgi?id=1732178 -- Jun Aruga | He - His - Him ___ 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: aarch64 test systems implementation
On Thu, Sep 19, 2019 at 12:28 PM Dave Love wrote: > > Are the aarch64 test systems running on real or emulated hardware? (Is > there a way to tell?) > > I ask because I'm seeing bad numerical results from a test and would > like to know if I can eliminate qemu as a possible cause -- not that I > think that's likely. Do you mean a system to test SRPM on aarch64? or a system to test a open source code? Do you mean CI testing system or an aarch64 server for adhoc test? ___ 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: Renewing the Modularity objective
> I'd suggest that the Modularity team could preapre a list of example > use cases that will present the strenghts of the modularity. I just share below my project for me to investigate use cases to switch a modules stream with Fedora (and RHEL) container and Travis CI. It's not general module examples but only examples to switch a module. But I believe that the way to show the example with actual command lines with the Fedora container and Travis CI helps someone to advocate the list of the example use cases. https://github.com/junaruga/switch-module-stream -- Jun | He - His - Him ___ 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: aarch64 test systems implementation
> > Do you mean a system to test SRPM on aarch64? or a system to test a > > open source code? > > Do you mean CI testing system or an aarch64 server for adhoc test? > > I don't know why it matters, but I'm testing dynamic micro-architecture > selection added to a library I've packaged. Because there are some proper choices depending on the situation. * Test by mock command (aarch64 qemu environment). (SRPM, adhoc) https://github.com/rpm-software-management/mock/wiki/Feature-forcearch * Test by Koji (aarch64 native) (SRPM, a kind of CI) * Test by Copr (aarch64 native or qemu. I am not sure) * Test by Packit service (aarch64 native, maybe) (SRPM, CI) * Test qemu-user-static RPM and aarch64 container * on local (Source, adhoc) * with CI services (Source, CI) * Test with Travis CI with qemu (aarch64 qemu environment) (Source, CI) * Test with native aarch64 supporting CI (Source CI) * only CI: Shippable CI, Drone CI, * Works on ARM (free aarch64 server for open source) (Source, adhoc or CI) For 2nd half, below documents might be helpful for you. * https://github.com/junaruga/fedora-workshop-multiarch * https://github.com/junaruga/ci-multi-arch-test Jun ___ 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: Question about package module development
> I'm working on (learning modularity) and developing a module for my package > and created a not-so-great (super long) branch name in the dist-git rpm and > module repo before I realized that it would be the stream's name too. I faced similar situation. Ruby module was released as "private-jaruga-master" stream. Now the branch is empty, as we can not delete it. https://src.fedoraproject.org/modules/ruby/tree/private-jaruga-master > Also, it seems that the incomplete module was picked up and included in F31 Policy Decision: In-development streams https://pagure.io/modularity/issue/156#comment-600856 Right now "master", "devel" and "rolling" stream names are used to test a module before releasing version "X.Y" stream. it's unofficial way. There is a discussion about it on above URL. > someone was nice enough to open a BZ and tell me it's broken. Agree. Some checks before releasing are useful. > but is there a way for me to hide (or something) that branch and use the > correct one that I just requested? Yes, you can hide the branch from the result of "dnf module list". I asked it to someone to hide "private-jaruga-master" stream. But I forget the way. > but wanted to ask first since I can't find any supporting documentation. Or > now that it's been included in F31 am I stuck with it (even thought it > doesn't work)? This is the documentation. But I do not think it is covering your concerns. https://docs.fedoraproject.org/en-US/modularity/making-modules/ -- Jun ___ 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: Question about package module development
>> Yes, you can hide the branch from the result of "dnf module list". I >> asked it to someone to hide "private-jaruga-master" stream. >> But I forget the way. > > > Maybe someone else can help :D I remembered the way after searching my past emails. :D You can open a ticket on releng to hide it like this. Untag modules/ruby stream private-jaruga-master from fedora-modular-30 repo https://pagure.io/releng/issue/8279 -- Jun | He - His - Him ___ 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
Review swap (htslib)
Hi all, Someone (especially proven packagers), could you review below library package related to bio science? It has already been reviewed several times. I think I fixed every items mentioned by a reviewer. Review Request: htslib - C library for high-throughput sequencing data formats (required for `samtools`) https://bugzilla.redhat.com/show_bug.cgi?id=1326504 Happy to review anything in exchange. Thanks. -- Jun | He - His - Him ___ 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: 2020 Datacenter Move: Request for comments
HI Ben, > Where does Communishift fit in here? I didn't see it mentioned. Could you explain about the meaning of the word "Communishift" in plain English? As I am not a native English speaker, I do not understand the actual meaning. Maybe does it mean a kind of behavior? -- Jun | He - His - Him ___ 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: 2020 Datacenter Move: Request for comments
> > Could you explain about the meaning of the word "Communishift" in plain > > English? > > Communishift is the OpenShift cluster that Infra runs for > community-run applications[1]. Its name is a portmanteau of > "Community" and "OpenShift". > > [1] https://fedoraproject.org/wiki/Infrastructure/Communishift Thanks for the explanation. I understand it. ___ 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: 2020 Datacenter Move: Request for comments
> There's also a video about it from Flock 2019: > https://www.youtube.com/watch?v=phCHilTEQb4=PL0x39xti0_64C75dRUuwlXlfYRgjgdEP4=8=0s Thanks. But why is the video mode "Unlisted" not public? -- Jun | He - His - Him ___ 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: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)
> Does anyone know of, or have, any critical/important use cases that would be disrupted by QEMU dropping 32-bit *host* support ? If so, let me know here & I can forward feedback on. Or feel free to go direct to QEMU thread upstream. I am not a real user of ARM 32-bit. I just checked information for ARM 32-bit (armv7) use cases. ## Raspberry Pi > https://en.wikipedia.org/wiki/Raspberry_Pi > The earlier V1.1 model of the Raspberry Pi 2 used a Broadcom BCM2836 SoC with > a 900 MHz 32-bit, quad-core ARM Cortex-A7 processor, with 256 KB shared L2 > cache. > > https://www.raspberrypi.org/blog/raspberry-pi-2-on-sale/ It seems that the version 1.1 is the last model for 32-bit, and the announcement was 5 August 2015. I assume a considerable number of people using ARM 32-bit Raspberry Pi. ## Running Linux on smart phone device. Some articles about it. * https://developers.redhat.com/blog/2017/03/16/installing-linux-on-an-android-phone/ * https://www.quora.com/How-can-I-install-Fedora-on-my-smartphone > https://android.stackexchange.com/a/202022 ARMv7 (32-bit) was 98.1% in entire share of android hardware on March 2017. > https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06216.html > Eventually this public don't need edge QEMU, it might keep using QEMU v5.0.stable until all NAS/embedded devices are 64-bit... For example, how about releasing compat-qemu50 RPM if upstream will drop armv7 on qemu 6.x? It's like compat-openssl10 RPM for openssl (version 1.1) RPM. Maybe if some RPM packages need armv7 support, they can use compat-qemu50 conditionally in the spec file. Jun ___ 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: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)
> For example, how about releasing compat-qemu50 RPM if upstream will > drop armv7 on qemu 6.x? > It's like compat-openssl10 RPM for openssl (version 1.1) RPM. > > Maybe if some RPM packages need armv7 support, they can use > compat-qemu50 conditionally in the spec file. Sorry. Typo. s/compat-qemu50/compat-qemu5/ Jun ___ 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: List of Python 2 packages to be removed mid-November (= in a week)
> ## What exactly is happening? > > The formal change proposal is here: > https://fedoraproject.org/wiki/Changes/RetirePython2 > > Packages requiring Python 2 will be removed starting November 15 (unless > they have an exception). > Components with all essential subpackages removed will be retired. > The removal will be (semi-)automated. > > Source packages only BuildRequiring removed packages will fail to build, > and will be removed according to the regular FTBFS policy. Will this happen only for rawhide? How about f31, f30, f29 branch? -- Jun | He - His - Him ___ 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: Help with rubygem packaging
For linked-list,
> + ruby -Ilib:. -e 'Dir.glob "test/**/test_*.rb", (:require)'
...
> 0 runs, 0 assertions, 0 failures, 0 errors, 0 skips
> + popd
"test/**/test_*.rb" you are using is incorrect in this case, and
different from the guideline. The test files were not captured..
"./test/**/*_test.rb" works possibly.
```
$ find . -name "test_*.rb"
./linked-list-0.0.13/test/test_helper.rb
$ find . -name "*_test.rb"
./linked-list-0.0.13/test/list_test.rb
./linked-list-0.0.13/test/node_test.rb
./linked-list-0.0.13/test/conversions_test.rb
```
For hrx,
> Looks like %check for hrx is a no go due to missing dep that isn't present in
> the repo
>
> + pushd ./usr/share/gems/gems/hrx-1.0.0
> ~/rpmbuild/BUILD/hrx-1.0.0/usr/share/gems/gems/hrx-1.0.0
> ~/rpmbuild/BUILD/hrx-1.0.0
> + ln -s /home/leigh/rpmbuild/BUILD/spec spec
> + rspec -rspec_helper spec
>
> An error occurred while loading ./spec/archive_spec.rb.
> Failure/Error: require 'rspec/temp_dir'
You see the missing dep 'rspec/temp_dir' is a testing dep.
```
$ cat hrx-1.0.0/Gemfile
...
gem "rspec-temp_dir", "~> 1.0", group: :test
```
We are trying to run a unit tests as much as possible, commenting out
or skipping the testing dep specific logic.
When you have %check section, I think that you feel more secure.
You learned commenting out not used dep like `sed -i '/bundler/
s/^/#/' Rakefile`.
You can adapt the way to this "rspec/temp_dir" case too like this.
```
$ sed -i "/require 'rspec\/temp_dir'/ s/^/#/" spec/archive_spec.rb
```
And you see the temp_dir rubygem dep is used for only
spec/archive_spec.rb context "::load" and "#write!".
```
$ grep -r temp_dir spec/
```
spec/archive_spec.rb
```
context "::load" do
...
end
context "#write!" do
...
end
...
```
You can adapt the way to comment out the specific lines like this.
```
$ sed -i '/^ context "::load" do$/,/^ end$/ s/^/#/' spec/archive_spec.rb
$ sed -i '/^ context "#write!" do$/,/^ end$/ s/^/#/' spec/archive_spec.rb
```
Or if the entire unit case does not work due to the missing testing
dep, you can just rename the test file to be skipped by rspec like
this.
```
$ mv spec/archive_spec.rb{,.disabled}
```
There is a good way to see all the RPM spec file easily. You can do
grep to see the examples.
(I think if this way is not documented, it is useful to be documented
somewhere in the guideline).
```
$ wget http://src.fedoraproject.org/repo/rpm-specs-latest.tar.xz
$ tar xvf rpm-specs-latest.tar.xz
$ ls rpm-specs/*.spec | wc -l
21514
```
--
Jun | He - His - Him
___
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: Announcing new anitya integration and de-orphaning process
> Existing status will be migrated from the fedora-scm-requests repo on pagure > to use this drop-down. > Using the fedora-scm-requests repo for the anitya integration will no longer > be supported. Thank you for the anitya integration feature. I have 2 questions. After the migration will be finished, 1. When just changing the "Monitoring status" drop-down button to "Monitoring" is good enough to receive the email "[Bug NNN] - is available"? Following steps are replaced with it, right? > https://fedoraproject.org/wiki/Upstream_release_monitoring > > Get bug reports for a project's releases in Fedora's Bugzilla with three > steps: > > 1. Add the project to anitya. > 2. Map the project to a Fedora package in anitya. > 3. File a pull-request on the releng/fedora-scm-requests repo to tweak the > monitoring setting for your packages. 2. Is it possible to put a link of a package's Antiya project page around "Monitoring status" of the rpm/foo page? It looks useful to know and edit the setting easily. For example. rpms/ruby https://src.fedoraproject.org/rpms/ruby => https://release-monitoring.org/project/4223/ -- Jun | He - His - Him ___ 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: moving bugzilla overrides to dist-git
> We are thinking on providing a simple text field to submit FAS username or > email to override the default assignee, the big question is then, who should > be allowed to update this field ? I like it's the same policy with editing the Setting page of https://src.fedoraproject.org/rpms/foo . > Should the main admin be able to set someone else as assignee ? Yes. > If there is already an override assignee, who should be allowed to change > that ? Main admin (maintainer) + other admin people can be allowed. > If there's no override assignee set, can everyone become it or is that up to > the main admin of the component to decide and set ? First, someone can take a main admin (maintainer) for https://src.fedoraproject.org/rpms/foo . Then the person can set. -- Jun | He - His - Him ___ 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: Announcing new anitya integration and de-orphaning process
> > 2. Is it possible to put a link of a package's Antiya project page > > around "Monitoring status" of the rpm/foo page? > > It looks useful to know and edit the setting easily. > > > > For example. rpms/ruby https://src.fedoraproject.org/rpms/ruby > > => https://release-monitoring.org/project/4223/ > > Technically doable, however, release-monitoring is distro agnostic, so I do > not > know if upstream will want to put too much Fedora specific content in it. You meant the "upstream" was release-monitoring (Antiya)? I thought we did not need to modify release-monitoring. I thought we need to modify Pagure: https://src.fedoraproject.org for that. If the Pagure upstream is the distro agnostic, how about adding a configuration item "Mappings Distribution" (Fedora/Alpine and etc) that is considered to access to release-monitoring from Pagure? > Adding a link from dist-git to release-monitoring should be easier, I even > seem > to remember that pkgdb2 used to do that, I'll have to see how it was doing it. Good news. If it is hard to implement it, just putting the following URL to search by a package name in release-monitoring is still helpful for me. https://release-monitoring.org/projects/search/?pattern= For example: https://release-monitoring.org/projects/search/?pattern=ruby -- Jun | He - His - Him ___ 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: Working fedora-active-user script?
> Following network graph of forks [1] we got the latest changes here [2] . > About add it to fedora-packager , seems to me a excellent idea. > > Best regards, > > [1] > https://github.com/pypingou/fedora-active-user/network > > [2] > https://github.com/junaruga/fedora-active-user/commits/feature/ci-py3-on-didier13150-master Yeah, the junaruga's [2] works for me. I am waiting for the pull-request (including [2]) that will be merged with enabling the Travis CI. @pypingou could you check and merge the code? https://github.com/pypingou/fedora-active-user/pull/14 Jun Aruga ___ 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: Working fedora-active-user script?
On Fri, Dec 13, 2019 at 12:17 PM Frank R Dana Jr. wrote: > > Hmmm. If there's a plan is to get it working again relatively soon, though, I > should probably withdraw my PR[1] to remove mention of it from the > Non-Responsive Maintainer Policy. (I figured, doesn't make sense to suggest a > tool that can't actually be used...) > > [1]: https://pagure.io/fesco/fesco-docs/pull-request/23 The fedora_cert missing dependency issue was fixed on the latest master branch [1], though the README is not updated yet. I believe that the script is actually used now. [1] https://github.com/pypingou/fedora-active-user -- Jun | He - His - Him ___ 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: Help with rubygem packaging
Hi Leigh,
Thank you for contributing the rubygem-* packages.
Let me comment for your *.spec files.
I recommend to compare the *.spec file generated by gem2rpm with your
*.spec file, and align basically.
The gem2rpm guides you.
How to do it (For example in case of Fedora 30)
```
$ sudo dnf install rubygem-gem2rpm
$ rpm -q rubygem-gem2rpm
rubygem-gem2rpm-1.0.1-3.fc30.noarch
$ gem fetch hrx
$ ls -l hrx-1.0.0.gem
$ gem2rpm hrx-1.0.0.gem > rubygem-hrx.spec
```
If you find some improvements for generated spec file, you can report it here.
https://github.com/fedora-ruby/gem2rpm
2. Adding %check section, as Jaroslav said.
Note that we do not use "bundler" ("bundle" command) and "rake"
command in RPM *.spec file.
3. Following *.spec files might be useful to refer.
https://src.fedoraproject.org/rpms/rubygem-listen/blob/master/f/rubygem-listen.spec
with Ruby C-extention.
https://src.fedoraproject.org/rpms/rubygem-rake/blob/master/f/rubygem-rake.spec
without Ruby C-extension.
"gem unpack" is useful to see the files in the *.gem file.
As hrx-1.0.0.gem and linked-list-0.0.13.gem are including the unit
test files in it,
Possibly "Source0" is good enough. Note above 2 *.spec files use
"Source1" too, as gem file does not include the unit test files.
```
$ gem unpack hrx-1.0.0.gem
Unpacked gem: '/home/jaruga/doc/memo/20191203_review_rubygem_pkgs/hrx-1.0.0'
```
Happy building!
--
Jun | He - His - Him
___
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: Help with rubygem packaging
> https://bugzilla.redhat.com/show_bug.cgi?id=1779403
> https://bugzilla.redhat.com/show_bug.cgi?id=1779404
I checked your uploaded *.spec files now a little bit.
I see that you are using "rake" in your rubygem-linked-list.spec,
and there is no %check section in your rubygem-hrx.spec.
> Note that we do not use "bundler" ("bundle" command) and "rake"
command in RPM *.spec file.
I am understanding that the reasons not using bundle and rake command
in the RPM *.spec file are
1. to simplify the build dependency tree.
2. to debug the unit tests easily if you face an issue in the unit test logic.
"bundle" and "rake" sometimes make you harder to debug, as they have
their own issues.
So, referring the Ruby guideline page - minitest and rspec test cases,
your *.spec files could be like this.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/#_testing_frameworks_usage
## rubygem-linked-list.spec
```
...
BuildRequires: rubygem(minitest)
...
%check
pushd .%{gem_instdir}
ruby -e 'Dir.glob "./test/**/*_test.rb", (:require)'
popd
```
## rubygem-hrx.spec
```
...
BuildRequires: rubygem(rspec)
...
%check
pushd .%{gem_instdir}
rspec -Ilib spec
popd
```
--
Jun | He - His - Him
___
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: Working fedora-active-user script?
> Nope, for the reason I've explained earlier in this thread. The proposed > changes > are (last time I've tried them) breaking the mailing-list checks which I don't > think is a good thing. Sure. Sorry I missed the reason you have explained earlier in the thread. -- Jun | He - His - Him ___ 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: Review swap (htslib)
Hi Zbigniew and Kevin Many thanks for your explanation. I clearly understand the htslib's situation now. -- Jun | He - His - Him ___ 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: Self Introduction: David McCheyne
On Mon, Oct 28, 2019 at 10:17 PM David W McCheyne wrote: > > Hello all. > New at packaging, here's my first review request: > https://bugzilla.redhat.com/show_bug.cgi?id=1766375 > > I recently started a new DevOps Engineer job at a company that pushes a lot > back out to the community, so this is my first contribution while I learn the > process. > Most of my past experience is in automation stacks, and python development as > well as general Linux SysAdmin stuff. I plan to try and contribute some other > python libraries in the future that I'm personally enthusiastic about, and > anything we generate in the office we can contribute back as well. Welcome, David. I appreciate your contributions. > New at packaging, here's my first review request: > https://bugzilla.redhat.com/show_bug.cgi?id=1766375 As the reviewing package is python-timeunit (python-*), I think Python SIG (Special Interest Group)'s people can help you for the review. I recommend you to join python-devel@ mailing list if you are interested in it. https://developer.fedoraproject.org/tech/languages/python/python-sig.html -- Jun | He - His - Him ___ 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
Review swap: bcftools
* Review Request: bcftools - Tools for genomic variant calling and manipulating VCF/BCF files https://bugzilla.redhat.com/show_bug.cgi?id=1774741 Bio science tool. C language. No sub package. This new package is necessary to upgrade current samtools 0.1 to 1.9. Because some functions in samtools 0.X had been split to bcftools. Thanks. -- Jun | He - His - Him ___ 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: Question about package module development
> So Modularity will happily unleash experimental branches that were never intended to be released onto unsuspecting users of stable releases? How can this not be an absolute showstopper? This failed Modularity experiment needs to end NOW! As far as I know, there was no rule for the branch name, first and now. The modularity team did not create any limitation intentionally. There was a discussion to limit branch name in a past time. That's the why each developer can create the branch technically. Of course I know there is a document of a version branch name for modularity. In case of fNN branch of rpms/foo, it is created by below command like this. For example: https://bugzilla.redhat.com/show_bug.cgi?id=1326504#c35 ``` $ fedpkg request-branch --repo htslib f31 https://pagure.io/releng/fedora-scm-requests/issue/17764 ``` When running "fedpkg request-branch" command, the ticket is created newly. Then, someone can check the branch is valid or not, before it is actually created. So, that's no problem. The branch can not be created wrongly. But in case of module, each developer can create any branch technically under their responsibility, but they can not remove the branch, even it is created by mistake, and released in a short term. The rule "developer can not remove the branch they created and released" was created before the age of modurarity. I feel the rule can be adjusted considering current situation of modularity. -- Jun | He - His - Him ___ 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: Review swap (htslib)
Someone, could give us advice about below situation, if the new package htslib's "/usr/lib64/libhts.so.1.9" is valid? "1.9" is upstream software's version. "2" is ABI's version (so version). ``` sh-5.0# ls -l /usr/lib64/libhts.so* lrwxrwxrwx 1 root root 13 Oct 2 23:50 /usr/lib64/libhts.so -> libhts.so.1.9 -rwxr-xr-x 1 root root 759680 Oct 2 23:50 /usr/lib64/libhts.so.1.9 lrwxrwxrwx 1 root root 13 Oct 2 23:50 /usr/lib64/libhts.so.2 -> libhts.so.1.9 ``` I thought it was valid, because we see many examples like following libraries. But there is an objection for that on the ticket. I think if the htslib pattern is wrong, we need to update the guideline. https://docs.fedoraproject.org/en-US/packaging-guidelines/ ``` $ ls -l /usr/lib64/libz.so* lrwxrwxrwx 1 root root 14 Aug 15 09:30 /usr/lib64/libz.so -> libz.so.1.2.11* lrwxrwxrwx 1 root root 14 Aug 15 09:30 /usr/lib64/libz.so.1 -> libz.so.1.2.11* -rwxr-xr-x 1 root root 128904 Aug 15 09:30 /usr/lib64/libz.so.1.2.11* ``` ``` $ find /usr/lib64 -name "lib*.so.*" -a -type f /usr/lib64/libKF5SyntaxHighlighting.so.5.59.0 /usr/lib64/libxcb.so.1.1.0 /usr/lib64/liburcu-common.so.6.0.0 ... $ find /usr/lib64 -name "lib*.so.*" -a -type f | wc -l 2082 ``` Could you comment here or on below ticket? Someone, could you be an sponsor of the reporter of the ticket? https://bugzilla.redhat.com/show_bug.cgi?id=1326504#c42 Thanks. -- Jun | He - His - Him ___ 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: [modularity] modularity team meeting minutes (Oct. 08, 2019)
> * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37) > * AGREED: We disagree with merging default streams into the main repo > as non-modular packages. Our approach is to implement a mechanism of > following default streams to give people the experience they want. > (+4 0 -0) (asamalik, 16:07:40) What is the consequence of this for module maintainers? Each module maintainer regularly does not have to update "fedora-module-defaults" repository's .yaml file any more? https://pagure.io/releng/fedora-module-defaults -- Jun | He - His - Him ___ 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: Package uses Gradle (retired) to build: what to do?
> Anyone with the time to (co-)maintain Gradle? :) I added Mikolaj and Daniel to TO. They had maintained gradle before being dead.package, seeing the past commits in rpms/gradle. Mikolaj and Daniel, do you like to come back as a maintainer of rpms/gradle? -- Jun | He - His - Him ___ 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
Adding Medical SIG package group and including bio-tech, biology
Hi, There are 3 topics for the Fedora Medical SIG in this email. ## Creating RPM group: medical-sig I would like to add "medical-sig" to the RPM groups that is listed on the page below. https://koschei.fedoraproject.org/groups Someone do you know how to create the group? ## Including bio-tech to Medical SIG Seeing the SIG's wiki page, right now Medical SIG is for Doctor/Dentist's healthcare system specific. https://fedoraproject.org/wiki/SIGs/FedoraMedical I want to update the Medical SIG's wiki page including bio-tech, biology content. In my opinion, a challenge for the medical, biology communities is the sustainability. Each medical and bio package maintainer in Fedora tends to manage their RPM packages in individual level. I want to make the Medical SIG the inclusive place the place to communicate and work collaboratively for the RPM packages. A good role model for the concept of Medical SIG is Debian Med team. https://wiki.debian.org/DebianMed > The Debian Med project prepares packages that are associated with medicine, > pre-clinical research, and life sciences. Its developments are mostly focused > on three areas for the moment: medical practice, imaging and bioinformatics. I want to adapt the concept to Fedora Medical SIG. https://blends.debian.org/med/tasks/ Biology is the sub category of the Medical in the Debian Med project. Well, for example working for creating a yogurt that has a strength for the disease sequencing the yogurt bacteria genome is not medical. But aligning with Debian Medical project is still meaningful for me. Any thoughts? ## Promotion! If you are interested in Medical/Biology, please join us to Medical SIG! It's a very moderate traffic group right now. https://lists.fedoraproject.org/archives/list/medical-...@lists.fedorahosted.org/ => Manage subscription Mailing list address: medical-...@lists.fedorahosted.org Cheers, Jun -- Jun | He - His - Him ___ 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: Adding Medical SIG package group and including bio-tech, biology
> ## Creating RPM group: medical-sig > > I would like to add "medical-sig" to the RPM groups that is listed on > the page below. > https://koschei.fedoraproject.org/groups > Someone do you know how to create the group? I want both "medical-sig" and "biology" group. "medical-sig" group is to manage and list all packages managed at medical sig with FAS group "medical-packagers-sig". It's like "go-sig". https://koschei.fedoraproject.org/groups/go-sig "biology" group is just to manage and list the sub category biology of the medical packages. It's like "ruby-rails". I do not need the FAS group. https://koschei.fedoraproject.org/groups/ruby-rails It might be used as the group install. https://developer.fedoraproject.org/tech/languages/ruby/ror-installation.html > $ sudo dnf group install 'Ruby on Rails' -- Jun | He - His - Him ___ 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: Let's talk about Fedora in the '20s!
> In my experience, in 1999 I was living in the same region with an NGO > working for a backbone network. > And the NGO helped me to put my Linux server in their network for free. > In the age of non-democratized computer and internet, some > organizations helped for the new technologies. My mistake. Maybe it was not "NGO" but "NPO" (NonProfit Organization). -- Jun | He - His - Him ___ 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: Let's talk about Fedora in the '20s!
> First, I'd like to see Fedora become more of an "operating system factory". 20s is from 2020 to 2029. 10 years. So long. So, let me write high level thoughts. And let me post a new topic. For the topic 'more of an "operating system factory"', I want to see Fedora project as a place to "democratize new technologies". Nowadays many people can use the computer and internet with relatively affordable cost, not depending on a belonging organization or region. That means those are democratized. But back to 1960s, 70s, 90s, only a few people who have access to the specific academia and companies or in specific regions could use those technologies relatively easier. For example, someone living near a company could use a computer for free for only weekend by negotiating the company. In my experience, in 1999 I was living in the same region with an NGO working for a backbone network. And the NGO helped me to put my Linux server in their network for free. In the age of non-democratized computer and internet, some organizations helped for the new technologies. Now there are not democratized digital tools and hardware again. The history repeats. I assume people want to use non-x86_64 servers to debug their application program with affordable cost I saw it working in upstream projects. I was asking to use s390x and ppc64le server to debug an application by sending email on Fedora. But after 2 weeks, no response. The operation could be improved. https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers When you keep looking at the community using new technologies with open source, some hardware are necessary. This tendency could be increased in the 20s. What resource helps a technology democratized? This can be a question to know what Fedora does, when you attend an event. Fedora's theme in 20s can be "democratizing to the access to the new technologies". And the actions are * Enable non-x86_64 servers for users easily with time sharing. * Enable hardware for users that is necessary to use technology. With time sharing? How to do it? It's a challenge. Regards, Jun -- Jun | He - His - Him ___ 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: Package uses Gradle (retired) to build: what to do?
> and why gradle was retired ? is easy unretire it ? I am running gradle command right now as a coincidence . The upstream project is active. https://github.com/gradle/gradle We also might refer other distribution's spec files if we unretire. https://software.opensuse.org/package/gradle https://tracker.debian.org/pkg/gradle -- Jun | He - His - Him ___ 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: Package uses Gradle (retired) to build: what to do?
> netcdf-java[1] uses the Gradle build system, and is required to update hdfview[2] to the latest version. Gradle, however, was retired[3] as "out of date, broken, fails to build, basically unmaintainable". Checking the build.grade file (gradle recipe filei) of netcdf-java, is it possible to build and run it with "javac" and "java" command without "gradle"? https://github.com/Unidata/netcdf-java/blob/master/build.gradle -- Jun | He - His - Him ___ 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: Package uses Gradle (retired) to build: what to do?
Hi Mikolaj, Thanks for your info and recommendation. > Currently I don't have time to maintain Gradle in Fedora. Several of my packages are built with Gradle by their upstreams, but currently it is more feasible to port packages to be built with Maven rather than maintaining Gradle in Fedora. But this may change in the future - as more projects start to use Gradle I may decide to take up its maintenance in upcoming years. > There are several different ways to handle this problem. In this case my recommendation is to port packages to be built with Maven instead of Gradle. Shall we write something about the Gradle's situation to the wiki Packaging:Java page? https://fedoraproject.org/wiki/Packaging:Java I think that it helps other Java packagers. -- Jun | He - His - Him ___ 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: What would it take to drop release and changelog from our spec files? (and do we want to?)
When removing the changelog in a spec file, users (not package maintainers) using this command are disappointed? ``` $ rpm -q --changelog python3 * Tue Oct 15 2019 Miro Hrončok - 3.7.5-1 - Update to 3.7.5 ... ``` -- Jun | He - His - Him ___ 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: Two stage Ruby compilation / Bootstrapping
> With recent changes, such as [3], I am afraid that the day has come. It seems that the day came on Ruby 2.7.0, right? Ruby 2.7.0 includes the commit [3]. > Thoughts? > On the positive side, 1(2) would allow us to stay better in line with > "Pregenerated code" guidelines [5], because there is already quite a lot > of pre-generated code shipped in Ruby release tarball. For my first impression,, I agree with the way 1) and 2). > 2) Use previous version of Ruby available in Fedora to bootstrap Ruby. > But this does not work ATM, at least when RubyGems are installed. And > upstream is doing what they can to make RubyGems inseparable [4]. If we create the SRPM for "Use previous version of Ruby available in Fedora to bootstrap Ruby", which name do you like? The candidates: * rpms/ruby-bootstrap * rpms/bootstrap-ruby * rpms/previous-ruby -- Jun | He - His - Him ___ 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: Outage: Migration of Copr servers - 2020-02-23 06:00 UTC
> Also, please know that we needed to temporarily disable ppc64le chroots (as it was previously announced) because at this moment we don't have access to any builders on that architecture. Any update for Copr ppc64le chroots? -- Jun | He - His - Him ___ 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: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)
> jaruga: nodejs-source-map-support, jruby I am okay to let nodejs-source-map-support orphan. I have no idea why nodejs-source-map-support affects me. Jun -- Jun | He - His - Him ___ 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: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)
> Follow the trail: uglify-js requires nodejs-acorn, which requires > nodejs-rollup, which requires that. Ah thanks for checking it. I should run `dnf repoquery --whatrequres` more. Can someone take uglify-js as a main maintainer? I can give it to you. https://src.fedoraproject.org/rpms/uglify-js As it is required by rubygem-uglifier that is one of the Ruby on Rails dependency packages, but I can bundle uglify-js in it, even when uglifyjs is orphaned. -- Jun | He - His - Him ___ 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: Packit-as-a-Service case studies and tips
> * How to manage a RPM spec file on the upstream repository, synchronizing it with Fedora rawhide's one. As my first step, I am trying to use Packit, having separately managed the RPM spec file that is only used to run the %check section on the Fedora scratch build at the pull-request in the upstream. Seeing the resources such as https://github.com/packit-service/packit . -- Jun | He - His - Him ___ 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: Outage: Migration of Copr servers - 2020-02-23 06:00 UTC
> > Any update for Copr ppc64le chroots? > > Not yet, the HW is still not assembled in new lab. > > Pavel Do you know when it will be available? If it takes some time, how about using qemu emulation for the ppc64le chroot for now? -- Jun | He - His - Him ___ 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
Review Swap: simde - SIMD Everywhere
Hi, Could anyone want to swap a review? Review Request: simde - SIMD Everywhere https://bugzilla.redhat.com/show_bug.cgi?id=1823001 simde [1] is a header files only library for a software implementing SIMD [2] to build with multiple CPU architectures. Thanks. Jun [1] https://github.com/nemequ/simde [2] SIMD: https://en.wikipedia.org/wiki/SIMD -- Jun | He - His - Him ___ 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: Outage: Migration of Copr servers - 2020-02-23 06:00 UTC
> > Fedora Infrastructure are in the middle of 2 data center moves currently > > with a COVID-19 lockdown affecting our ability to give any timelines of > > when things will be available. I do not think the servers will be available > > until May at the earliest and they will be a lower priority than keeping > > koji or other core Fedora services going. > > Yeah, this sounds OK. Good luck with the movement. Yeah, OK. Thanks for the work. > > Currently copr is running out of amazon and does not have emulation > > capabilities either. > > We already enabled emulated armhfp (on x86_64) builders in copr (that's > probably > what Jun meant)... it's the software emulation by qemu-user-static (mock > --forcearch). Yes, that is what I meant. The software emulation by qemu-user-static. > @Jun wrote: > > Any update for Copr ppc64le chroots? > > People were used to use native machines for ppc64le targets, so the > temporary switch to emulated variant could cause more harm then good here. > I'd rather wait till May for the native builders then mix-up. I agree with you. I am okay to wait rather than starting qemu-user-static emulation for ppc64le targets now. -- Jun | He - His - Him ___ 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: Heads up: OpenSSL-1.1.1e coming to Rawhide
> The list of (likely) affected packages is growing: > > https://koschei.fedoraproject.org/affected-by/openssl-libs?epoch1=1=1.1.1d=7.fc33=1=1.1.1e=1.fc33=f33 It's a useful list! Thanks. Note rubygem-puma is added to the list too. -- Jun | He - His - Him ___ 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
Koji is failing on s390x
Koji is failing to build before creating root.log and build.log on s390x right now. Is it a known issue? https://koji.fedoraproject.org/koji/taskinfo?taskID=42916760 https://koji.fedoraproject.org/koji/taskinfo?taskID=42916889 Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/koji/daemon.py", line 1294, in runTask response = (handler.run(),) File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 313, in run return koji.util.call_with_argcheck(self.handler, self.params, self.opts) File "/usr/lib/python3.7/site-packages/koji/util.py", line 263, in call_with_argcheck return fu ... -- Jun | He - His - Him ___ 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: Koji is failing on s390x
> should be https://pagure.io/koji/issue/1974 > > What's the size of the srpm? Thanks for sharing the info. It's 238 KB. ``` $ ls -hl rubygem-puma-4.3.3-1.fc32.src.rpm -rw-rw-r-- 1 jaruga jaruga 238K Mar 31 19:52 rubygem-puma-4.3.3-1.fc32.src.rpm ``` But it might be my fault. I was putting rubygem-puma-master.spec file as a backup. Then when running `fedpkg srpm`, it seems rubygem-puma-master.spec was included in the SRPM file rubygem-puma-4.3.3-1.fc32.src.rpm. It's a invalid state. ``` $ pwd /home/jaruga/fed/rubygem-puma $ ls ... rubygem-puma.spec rubygem-puma-master.spec ... ``` Now after removing the file, the build succeeded. Sorry for disturbing it. -- Jun | He - His - Him ___ 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
Packit-as-a-Service case studies and tips
I am considering using Packit-as-a-Service [1] for an upstream project, as the maintainer of the project suggested managing the RPM spec file on the upstream's repository in Github. Could you tell me some case studies of the upstream project using Packit-as-a-Service? I know rebase-helper [2] is using it. What I want to do is * to check the RPM spec file at the pull-request timing on GitHub, building it on specified build targets (rawhide or fNN). My questions are * How to manage a RPM spec file on the upstream repository, synchronizing it with Fedora rawhide's one. For example, in case of rawhide, the RPM spec file's release version is sometimes automatically updated. I am thinking of managing the RPM spec file on the upstream without %changelog to synchronize it easily. * Is it possible to manage the RPM spec file including %PatchN and the patch file on the upstream repository? [1] https://packit.dev/packit-as-a-service/ [2] https://github.com/rebase-helper/rebase-helper Thanks. -- Jun | He - His - Him ___ 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
RPM packages included in Medical and Biology category in Fedora?
I created lists of RPM packages in Medical and Biology using Koschei's group tag feature. The medical-sig tag is for medical, healthcare, biology, computing biology, bioinformatics. The biology tag is for biology, computing biology, bioinformatics, genomics. Could you tell me any other packages you know, included in the lists [1] and [2]? * Koschei tip 1: On the list page, you can switch the list by [Show untracked] / [Hide untracked] toggle button. * Koschei tip 2: To enable tracking the package on Koschei, click a gear button on the "Scheduler parameters" on the page such as [3] if you have the permission. [1] and [2] are linked from Fedora Medical SIG page [4]. Thanks. [1] https://koschei.fedoraproject.org/groups/medical-sig?untracked=1 [2] https://koschei.fedoraproject.org/groups/biology?untracked=1 [3] https://koschei.fedoraproject.org/package/bowtie [4] https://fedoraproject.org/wiki/SIGs/Medical -- Jun | He - His - Him ___ 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: What CPU extensions can we assume are available by arch?
> > For the better user experience, we are promoting the system library > > for both RPM and Debian based Linux distributions. > > What system library, for what purpose? Hi Dave, The simde system library is * simde-devel in Fedora and EPEL [1] * libsimde-dev in Debian [2] The purpose is to build and ship SIMD implemented software RPM such as bowite2 [3] and minimap2 [4] on non-x86_64 CPU architecture such as aarch64, ppc64le and s390x. [1] https://src.fedoraproject.org/rpms/simde/ [2] https://wiki.debian.org/SIMDEverywhere [3] https://raw.githubusercontent.com/junaruga/fedora-bowtie2/master/bowtie2.spec In review status on https://bugzilla.redhat.com/show_bug.cgi?id=1824348 . [4] https://github.com/lh3/minimap2 -- Jun | He - His - Him ___ 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: CMake3-3.17.1 on EPEL7
Thanks for maintaining it. I did not know we can use CMake 3 with cmake3 RPM on EPEL7. Jun -- Jun | He - His - Him ___ 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
