Re: Orphaning some of my packages
Excerpts from Dan Callaghan's message of 2022-03-06 20:13:26 +11:00: > python-phonenumbers I took python-phonenumbers back. I forgot that it's in the dependency chain of matrix-synapse which I very much still use. -- Dan Callaghan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Orphaning some of my packages
Lately I haven't had much time to contribute to Fedora packaging and I'm not using Fedora/EPEL much, so I've decided to orphan all the packages which I no longer use: ansible-review beanstalk-client bmap-tools ghc-dbus ghc-libxml-sax linenoise lua-ldap nodejs-backbone nodejs-grunt-sed python-aiohttp-negotiate python-blessings python-fastimport python-lrparsing python-nose-progressive python-ofxparse python-phonenumbers python-plyvel python-pystalk python-unidiff qcommandline -- Dan Callaghan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
python-pytest-randomly changing license from BSD to MIT
Starting from version 3.5.0 the python-pytest-randomly package has changed license from BSD to MIT. I will build this update for rawhide shortly. -- Dan Callaghan ___ 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 in rawhide (2018-08-27)
Excerpts from Zbigniew Jędrzejewski-Szmek's message of 2018-08-28 08:38 +00:00: > On Tue, Aug 28, 2018 at 04:56:58PM +1000, Dan Callaghan wrote: > > What does it mean for a package to be owned by orphan while it still > > has other admins who are real people? > > > > Is this some kind of edge case where the package was owned by > > a maintainer who was inactive, and thus their packages got "orphaned", > > even though there are still other maintainers? Is there any record where > > we can see when or why these changes were made? > > Hi, > > FESCo voted yesterday to "send info to all co-maintainers and > fedora-devel, [...] after a week reassign to one co-maintainer, if no > co-maintainers, retire". The text in Till's mail was not adjusted to > reflect this. Nevertheless, the plan is to do what was voted. > > The reason why we don't just reassign all packages to co-maintainers > right now is that often it's not clear which if any of the other > maintainers are active. So in this first round we ask people to > take ownership explicitly, and will do the automatic procedure for > the rest. > > > And is the solution here that one of the existing co-maintainers should > > just go into the Pagure settings and click... some button to become the > > "main admin" so that it's no longer orphaned? > > Unfortunately there is no "button" in pagure, and the process to take > a package is a manual releng ticket. > > Yeah, it's all quite a bit more manual and messy than it should be. Thanks for the explanation, this was the context I was missing. I have filed a ticket about reassigning python-configobj, we can sort it out between the existing co-maintainers (whichever are still active) in the ticket: https://pagure.io/releng/issue/7727 -- Dan Callaghan Senior Software Engineer, Products & Technologies DevOps Red Hat signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned Packages in rawhide (2018-08-27)
Excerpts from Till Maas's message of 2018-08-28 00:03 +02:00: > python-configobj fale, lmacken, orphan, 45 weeks ago >terjeros [...] I will take python-configobj if nobody else will... BUT I don't quite understand what this means. Pagure shows the owners as: orphan (orphan) - main admin Fabio Alessandro Locati (fale) - admin lmacken (lmacken) - admin Terje Røsten (terjeros) - commit The package has no open bugs and is not failing in Koschei so I do not see any reason why it needs to be retired. What does it mean for a package to be owned by orphan while it still has other admins who are real people? Is this some kind of edge case where the package was owned by a maintainer who was inactive, and thus their packages got "orphaned", even though there are still other maintainers? Is there any record where we can see when or why these changes were made? And is the solution here that one of the existing co-maintainers should just go into the Pagure settings and click... some button to become the "main admin" so that it's no longer orphaned? -- Dan Callaghan Senior Software Engineer, Products & Technologies DevOps Red Hat signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Auto-filing of FTBFS bugs gone wild
Excerpts from Miro Hrončok's message of 2018-07-19 17:48 +02:00: > I know it is not comfortable, yet at this point reverting the change > and doing another mass rebuild is IMHO more work than fixing the > packages. Also, let me take this opportunity to give Koschei a shout-out. I have it enabled on all my packages and the handful of packages which Igor's script did not automatically fix for me, Koschei immediately told me about. And I was able to fix them up earlier this week, before the FTBFS bugs were filed. I strongly recommend everyone turns Koschei tracking on for all their packages because it makes it quite easy to find problems like this. (Sadly, you do get a bit more noise when pushes something that breaks the entire distro, but it's still worth it.) -- Dan Callaghan Senior Software Engineer, Products & Technologies DevOps Red Hat signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7CUNCDCACGUZULT4QCDUIITUCXVGALOE/
[EPEL-devel] Re: How to clean up EPEL 7 broken repoclosure
Excerpts from Till Maas's message of 2017-08-25 10:55 +02:00: > On Thu, Aug 24, 2017 at 06:16:48PM -0400, Stephen John Smoogen wrote: > > TurboGears-1.1.3-8.el7.noarch > > I guess some of the packages are broken because they were improperly > unretired and unintentionally retired again: > https://pagure.io/releng/issue/6945 > > It might be that the individual maintainers are not yet aware of their > packages being broken because AFAIK there is no notification of packages > being retired in PDC, yet. Yes indeed. The TurboGears repoclosure problem will go away in two more weeks when its rebuilt dependencies go stable. But there are likely others in this list caused by the same issue. -- Dan Callaghan <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Re: Fedora's beaker instance
Sorry for my very slow reply Petr... Excerpts from pschindl's message of 2017-08-08 17:24 +02:00: > Hi Dan, > > I have few questions regarding a beaker.qa.fp.org. What is the state of > the project right now? I now work with DesktopQA team on upstreaming > their tests. And because they run their tests on internal beaker so I'd > like to mimic their workflow. So I'd like to try to run tests on our > Fedora's beaker. > > So my questions. Does the beaker.qa.fp.org works at all? Could you give > me access to at least one machine? Can I help you somehow with make it > work? What can I do to put F26 or Rawhide trees to Beaker? > > Thank you for your answers. Have a nice day. With regards > Petr Schindler (Fedora QA) I've cc'ed the Fedora qa-devel list. Tim Flink did a lot of work getting the Fedora Beaker instance set up. If you wanted to get access to use it, I'm sure we could do that. We would just need to add you to this group: https://beaker.qa.fedoraproject.org/groups/qa-beaker-users#members As far as I know, Beaker itself is fully up and running now (we had some issues with Fedora authentication but they were all sorted out a while back). However it looks like the Dell machines attached to Beaker are not successfully booting into the installer right now. Tim might know more about what is missing/broken with them. I'm not entirely sure what's wrong because I don't think I have access to their serial console. That reminds me, one thing we never did set up properly is a Conserver instance so that Beaker can scrape the serial console logs. That would certainly make it easier to see why the Dell machines aren't netbooting successfully. I should try and see about writing a playbook to deploy Conserver... -- Dan Callaghan <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat signature.asc Description: PGP signature ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Re: Outdated clamav database in Taskotron
Excerpts from Róman Joost's message of 2017-08-02 10:18 +10:00: > Dear Petr, > > On Tue, Aug 01, 2017 at 01:05:34PM +0200, Petr Pisar wrote: > > On Tue, Aug 01, 2017 at 11:59:41AM +0200, Kamil Paral wrote: > > > thanks for the report. In the task, we just install rpmgrill and run it. > > > If > > > rpmgrill reports outdated clamav results, it seems that's something that > > > should be fixed in rpmgrill itself (it could depend on clamav-update and > > > update the virus db before running the virus check). Can you please report > > > a bug against rpmgrill and post the link here? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1477130 > Many thanks for the report. I haven't looked into the specifics, but I'm > not sure what we envision rpmgrill should be doing here. Should it run a > freshclam every invokation of rpmgrill? From what I see, that can take > quite a bit of time. > > Maybe what could be done tho is a systemd timer installed with the > package which runs freshclam every now and than? This might not work well if rpmgrill is invoked as part of some system which creates a fresh VM from scratch and then deletes it shortly after (think single-use slaves with Jenkins OpenStack Cloud plugin, for example). The freshclam timer will likely never trigger before rpmgrill is run. One possible thing which might help is if rpmgrill could warn or even fail, if it detects that it's being run with "outdated" ClamAV definitions. Not sure how old you want to consider "outdated", or if there is an easy way to check it... At worst I guess something like, if modtime of ClamAV definitions is more than 4 weeks in the past give an error? Do we know how frequently the definitions are updated? The other thing is that this idea of "download some data from the internet in order to make this package work" is not a good approach. It breaks in exactly the scenario I mentioned above, where a freshly installed copy of the package is not actually usable. The pciids and usbids database used to be like this too (shipping some old version of the data, plus a cron job to pull down updates from the internet) but nowadays we have the hwdata package which just gets updated with the latest definitions once per month. This is a much nicer solution because it means you can install a machine using only Fedora packages (or a freshly built disk image) and it already has the data it needs, without then going back to some random server on the internet. So maybe the ClamAV definitions should be treated similarly? In a separate package which gets updated on a regular interval to pull in the latest data? -- Dan Callaghan <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat signature.asc Description: PGP signature ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
python-gevent will be rebased to 1.2.2 in rawhide
If there are no objections, later this week I will update python-gevent in rawhide to 1.2.2. We have 1.1.2 in rawhide currently. There are some incompatible changes in the 1.2.x series of gevent, please see the upstream release notes here: http://www.gevent.org/changelog.html#a1-oct-27-2016 I found the following packages which depend on python*-gevent in rawhide: pykka python-gevent-socketio python-gevent-websocket python-mwlib python-parallel-ssh python-psycogreen python-qserve python-tinyrpc python-x2go Of those, only python-mwlib appears to be affected by the module removals in gevent 1.2.x, I filed bug 1459389. For all other callers of gevent, please check if your package might be affected. Note that the first upstream alpha of 1.2.x was first released more than 9 months ago, so callers should have adjusted to the changes upstream by now. -- Dan Callaghan <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: sysadmin-qa group for deploying waiverdb
Excerpts from Tim Flink's message of 2017-05-09 10:53 -04:00: > I've added and sponsored mjia to sysadmin-qa. Thanks! > Dan, I assume that you'll be helping him figure out the bastion hosts > etc.? Yep will do. -- Dan Callaghan <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat signature.asc Description: PGP signature ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Re: New list for ResultsDB users
Excerpts from Adam Williamson's message of 2017-02-15 16:13 -08:00: > Please note: despite the list being a fedoraproject one, the intent is > to co-ordinate with folks from CentOS, Red Hat and maybe even further > afield as well; we're just using an fp.o list as it's a quick > convenient way to get a nice mailman3/hyperkitty list without having to > go set up a list server on taskotron.org or something. I realise this is now way too late so just a small tip for next time... There is also list hosting available on the fedorahosted.org domain, for example we have a Beaker list hosted on there. It is nice because Fedora infra still does all the hard work of hosting it :-) but the domain implies a slightly looser relationship to the Fedora project. AFAIK the lists on fedorahosted.org are not affected by any of the Trac decomissioning work. -- Dan Callaghan <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat signature.asc Description: PGP signature ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir
Excerpts from Tom Hughes's message of 2016-05-12 09:15 +01:00: > On 12/05/16 09:07, Tomasz Torcz wrote: > >Shouldn't that be /usr/lib/distro.repos.d (for > >distribution-provided > > data) with usual rules for overriding/masking in /etc/distro.repos.d (for > > local administrator)? > > Well equally isn't the "distro." prefix all wrong if it includes things > other than distribution provided repositories... Agreed... if end users and third-party repos are expected to also put their configs into this directory, then having "distro" in the name doesn't really make sense. If the objection to yum.repos.d is that they are not just "yum repos" anymore, since clients other than yum can consume them -- then maybe we can think of them as "yum-formatted package repos" (that is, "repositories of RPM packages with metadata in the format originated by yum"). In that case, yum.repos.d still seems reasonable to me, but if you *really* want to avoid the word "yum" in there then maybe package-repos.d or package.repos.d or packagerepos.d? -- Dan Callaghan <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: glibc in Fedora rawhide now split by langpacks.
Excerpts from Carlos O'Donell's message of 2016-02-29 11:04 -05:00: > On 02/29/2016 06:32 AM, Petr Pisar wrote: > > Mock (or rpmbuild?) sets LANG to en_US.UTF-8 instead of C in order > > to > > have UTF-8 locale when building packages because it was decided that > > UTF-8 is the default (build) environment for Fedora. > > > > With removing en_US.UTF-8 from the glibc and thus minimal build root, > > all koji builds are misconfigured now because setlocale(3) on "en_US.UTF-8" > > fails without the locale definition in the file system. One of my Python packages' tests failed in Koschei due to (I think) the same issue. The tests were failing in Python 3 because now sys.stdout is encoded as ASCII whereas it (presumably) should be UTF-8. > > I assume changing the default build-time locale to C.UTF-8 could help. > > The glibc team guarantees you will have C.UTF-8 always. > > It should be the default. > > This is indeed related to the langpack split up and we are going > to fix this shortly. When you say it will be fixed, do you mean fixed by changing Koji to run all builds in C.UTF-8 instead of en_US.UTF-8? Or fixed by ensuring that en_US.UTF-8 is available in the build environment (by adding it to the Koji build group I guess)? Or some other fix? -- Dan Callaghan <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)
Excerpts from Jason L Tibbitts III's message of 2016-01-20 18:49 -06:00: > Failures due to missing dependencies: 122 > arprec-2.2.18-1.el5.src.rpm [qd-devel] (besser82) > babel-0.9.5-2.el5.src.rpm [python26-distribute] (jcollie, fschwarz) > Cython-0.14.1-3.el5.src.rpm [python26-distribute] (stevetraylen) > dinotrace-9.4c-1.el5.src.rpm [emacs-verilog-mode] (chitlesh) > disktype-9-5.el5.src.rpm [libewf-devel] (richardfearn, kwizart) > euca2ools-2.1.3-1.el5.src.rpm [python26-setuptools] (gholms) > gdal-1.4.2-4.el5.src.rpm [xerces-c-devel] (devrim, pali, volter) > grin-1.1.1-3.el5.src.rpm [python-setuptools-devel] (hubbitus) > mnemosyne-1.2.1-1.el5.src.rpm [python-setuptools-devel] (rathann) > [...] All of these broken dependencies onto python-setuptools-devel seemed a little strange to me so I dug into it. In December 2013 python-setuptools was retired from EPEL5 because it moved into RHEL. But EPEL5 had 0.6c9-5.el5 whereas RHEL imported 0.6c5-2.el5. I never even noticed this, my RHEL5 VM (which apparently is older than 2013) still has the EPEL package because its version is higher. The other irritating difference between the packages is that the RHEL package didn't retain the (admittedly pointless) split into a -devel subpackage containing easy_install, everything is in the main python-setuptools package instead: dcallagh@erlenmeyer ~ $ rpm -q python-setuptools python-setuptools-devel python-setuptools-0.6c9-5.el5 python-setuptools-devel-0.6c9-5.el5 dcallagh@erlenmeyer ~ $ rpm -ql python-setuptools-devel /usr/bin/easy_install /usr/bin/easy_install-2.4 /usr/lib/python2.4/site-packages/easy_install.py /usr/lib/python2.4/site-packages/easy_install.pyc /usr/lib/python2.4/site-packages/easy_install.pyo /usr/share/doc/python-setuptools-devel-0.6c9 /usr/share/doc/python-setuptools-devel-0.6c9/EasyInstall.txt /usr/share/doc/python-setuptools-devel-0.6c9/README.txt /usr/share/doc/python-setuptools-devel-0.6c9/api_tests.txt /usr/share/doc/python-setuptools-devel-0.6c9/psfl.txt /usr/share/doc/python-setuptools-devel-0.6c9/zpl.txt dcallagh@erlenmeyer ~ $ rpm -ql python-setuptools /usr/lib/python2.4/site-packages/pkg_resources.py /usr/lib/python2.4/site-packages/pkg_resources.pyc /usr/lib/python2.4/site-packages/pkg_resources.pyo /usr/lib/python2.4/site-packages/setuptools [...] dcallagh@erlenmeyer ~ $ sudo repoquery python-setuptools python-setuptools-0:0.6c5-2.el5.noarch dcallagh@erlenmeyer ~ $ sudo repoquery -l python-setuptools /usr/bin/easy_install /usr/bin/easy_install-2.4 /usr/lib/python2.4/site-packages/easy_install.py /usr/lib/python2.4/site-packages/easy_install.pyc /usr/lib/python2.4/site-packages/easy_install.pyo /usr/lib/python2.4/site-packages/pkg_resources.py /usr/lib/python2.4/site-packages/pkg_resources.pyc /usr/lib/python2.4/site-packages/pkg_resources.pyo /usr/lib/python2.4/site-packages/setuptools [...] So it seems like we will just need to update all those broken EPEL5 packages to require python-setuptools instead of python-setuptools-devel. Hopefully there are no interfaces (or fixes) in the newer 0.6c9 version which EPEL packages were relying on... I will update any packages I have commit access to (which is just TurboGears I think). -- Dan Callaghan <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat, Inc. signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel]Re: python2-setuptools metapackage
Excerpts from John Dulaney's message of 2015-11-19 17:11 -05:00: > Since Fedora is now requiring python2 packages have a buildrequires > of python2-setuptools, I put together a quick metapackage(0)(1) that in turn > requires python-setuptools. This will make packaging for Fedora and > epel to be somewhat easier. > > What are your thoughts on this, and should we include this in epel? > > As an alternative, it may not be a bad idea to have one large metapackage > that builds sub-metapackages for the various similar situations. Thoughts > on this? Would it be easier to request the RHEL packages to add a virtual Provides for the python2-* name? That is, python-setuptools in RHEL could provide python2-setuptools. -- Dan Callaghan <dcall...@redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat, Inc. signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
Re: About making noarch package arch specific, when contents differ.
Excerpts from Peter Robinson's message of 2015-07-28 18:01 +10:00: This is completely NOT appropriate, it breaks on secondary arches where they then end up with no documentation due to the lack of any x86_64. Please DO NOT do this and please revert the change on any packages you might have made this change. I haven't used that hack on any of my packages but I learnt about it from the ipxe package which uses it to produce noarch subpackages containing boot images. I guess ipxe is broken on secondary arches as well, but it's acceptable for that package because the only alternative would be to make it x86-only? -- Dan Callaghan dcall...@redhat.com Senior Software Engineer, Products Technologies Operations Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About making noarch package arch specific, when contents differ.
Excerpts from paulo.cesar.pereira.de.andrade's message of 2015-07-27 00:05 +10:00: Should I make the doc packages arch specific? Rather than trying to make Sphinx spit out bitwise-identical output on every arch (which sounds like fighting a losing battle), could you just build the doc subpackage on only one arch? %ifarch x86_64 %package doc BuildArch: noarch ... %endif I think Koji still counts this a regular noarch subpackage and it should therefore be included in the Fedora trees for all arches. -- Dan Callaghan dcall...@redhat.com Senior Software Engineer, Products Technologies Operations Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] EPEL for z Systems s390x
Excerpts from Bryan Chan's message of 2015-06-24 08:29 +10:00: Dan Horák d...@danny.cz wrote on 2015-06-23 02:31:23 PM: On Tue, 23 Jun 2015 13:52:41 -0400 Filipe Miranda fmira...@redhat.com wrote: This can be addressed maybe by IBM, by offering build systems to help developers test their packages. Ack, that's something for IBM, from Red Hat side it would require providing RHEL for System z subscriptions to such devel systems. Currently we have one public guest running Fedora available to the community, so it should be solvable. In addition to real HW there are 2 solutions capable running current Linux distributions under emulation. Dan, could you elaborate on the emulation aspect? Do you mean IBM zPDT and Hercules? I am curious if you are using emulation in the build farm today. IBM is currently engaging open-source software companies to encourage support for the platform. IBM partners can essentially get access to hardware for development purposes at a discount. For the community, we have a program called Community Development System for Linux on z, whereby open source projects can sign up for free access to Linux guests on our z Systems (for a limited time): http://www-03.ibm.com/systems/z/os/linux/support/community.html During registration, you can request a RHEL installation. I am not sure whether it comes with a RHN subscription. Other community hardware access options are now being considered, and I hope something more streamlined can be announced soon. One possibility is to make some z/VM guests available to approved Fedora contributors using beaker.fedoraproject.org, the same way that Red Hat engineers can use our internal Beaker instance to reserve z/VM guests. I would love to see the arches that people don't have at home, like ppc64 and aarch64, on beaker.fedoraproject.org too. The only big unresolved issue with beaker.fedoraproject.org right now is how to hook up FAS authentication. I haven't had a chance to figure that out yet. -- Dan Callaghan dcall...@redhat.com Senior Software Engineer, Products Technologies Operations Red Hat, Inc. signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
erlang-jsx about to be retired (Re: Orphaned Packages in rawhide (2015-04-20))
requires infinispan = 6.0.2-5.fc21 resteasy (maintained by: vakwetu, edewata, goldmann, weli) resteasy-3.0.6-7.fc22.src requires mvn(org.infinispan:infinispan-core) = 6.0.2.Final resteasy-optional-3.0.6-7.fc22.noarch requires mvn(org.infinispan:infinispan-core) = 6.0.2.Final eclipse-jbosstools (maintained by: galileo, goldmann) eclipse-jbosstools-4.2.2-1.fc22.src requires wildfly = 8.1.0-3.fc22 eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires wildfly = 8.1.0-3.fc22 perl-Alien-ROOT (maintained by: ppisar, jplesnik, perl-sig, psabata) perl-Alien-ROOT-5.34.3.1-7.fc22.i686 requires root-core = 5.34.24-3.fc22 perl-Alien-ROOT-5.34.3.1-7.fc22.src requires root-core = 5.34.24-3.fc22 perl-SOOT (maintained by: ppisar, jplesnik, perl-sig, psabata) perl-SOOT-0.17-6.fc22.i686 requires libCint.so.5.34, libCore.so.5.34, libGpad.so.5.34, libGraf.so.5.34, libGraf3d.so.5.34, libHist.so.5.34, libMathCore.so.5.34, libMatrix.so.5.34, libNet.so.5.34, libPhysics.so.5.34, libPostscript.so.5.34, libRIO.so.5.34, libRint.so.5.34, libThread.so.5.34, libTree.so.5.34 perl-SOOT-0.17-6.fc22.src requires root-graf3d = 5.34.24-3.fc22, root-physics = 5.34.24-3.fc22, root-reflex = 5.34.24-3.fc22 rootplot (maintained by: stevetraylen) rootplot-2.2.1-10.fc21.i686 requires root-python = 5.34.24-3.fc22 rootplot-2.2.1-10.fc21.src requires root-python = 5.34.24-3.fc22 Depending on: python-sqlalchemy0.5 (1), status change: 2015-03-31 (2 weeks ago) python-migrate0.5 (maintained by: lmacken, mbacovsk) python-migrate0.5-0.5.4-7.fc21.noarch requires python-sqlalchemy0.5 = 0.5.8-11.fc19 python-migrate0.5-0.5.4-7.fc21.src requires python-sqlalchemy0.5 = 0.5.8-11.fc19 Affected (co)maintainers apevec: erlang-jsx besser82: erlang-jsx coolsvap: erlang-jsx ctubbsii: erlang-jsx dbruno: erlang-jsx dcallagh: erlang-jsx edewata: erlang-jsx ellert: erlang-jsx erlang-sig: erlang-jsx galileo: erlang-jsx georgiou: perl-File-SearchPath, perl-Term-Clui gholms: python-sockjs-tornado gil: erlang-jsx goldmann: erlang-jsx hchen: erlang-jsx itamarjp: obexftp java-sig: erlang-jsx jplesnik: erlang-jsx lalatendu: erlang-jsx lmacken: naim, pork, python-sqlalchemy0.5, xprobe2 matt: erlang-jsx mbacovsk: python-sqlalchemy0.5 mebourne: zoneminder mizdebsk: erlang-jsx moceap: erlang-jsx perl-sig: perl-File-SearchPath, perl-Term-Clui, erlang-jsx peter: erlang-jsx pmackinn: erlang-jsx ppisar: erlang-jsx psabata: erlang-jsx ricardo: erlang-jsx rrati: erlang-jsx silas: erlang-jsx smilner: identicurse stevetraylen: erlang-jsx sundaram: python-xkit, gnome-schedule, libgtkhotkey, xlhtml tstclair: erlang-jsx vakwetu: erlang-jsx weli: erlang-jsx willb: erlang-jsx Orphans (19): erlang-jsx gnome-schedule identicurse jackrabbit libgtkhotkey mercury naim netactview obexftp perl-File-SearchPath perl-Term-Clui pork python-sockjs-tornado python-sqlalchemy0.5 python-sqlamp python-xkit xlhtml xprobe2 zoneminder Orphans (dependend on) (2): erlang-jsx python-sqlalchemy0.5 Orphans (rawhide) for at least 6 weeks (dependend on) (1): erlang-jsx Orphans (rawhide)(not depended on) (17): gnome-schedule identicurse jackrabbit libgtkhotkey mercury naim netactview obexftp perl-File-SearchPath perl-Term-Clui pork python-sockjs-tornado python-sqlamp python-xkit xlhtml xprobe2 zoneminder Orphans (rawhide) for at least 6 weeks (not dependend on) (2): jackrabbit mercury Depending packages (rawhide) (29): accumulo amplab-tachyon avro eclipse-jbosstools glusterfs-hadoop hadoop hbase hibernate hibernate-hql hibernate-search hive htrace infinispan oozie parquet-format perl-Alien-ROOT perl-SOOT picketbox pig python-elasticsearch python-migrate0.5 python-txamqp resteasy root rootplot solr spark thrift wildfly Packages depending on packages orphaned (rawhide) for more than 6 weeks (28): accumulo amplab-tachyon avro eclipse-jbosstools glusterfs-hadoop hadoop hbase hibernate hibernate-hql hibernate-search hive htrace infinispan oozie parquet-format perl-Alien-ROOT perl-SOOT picketbox pig python-elasticsearch python-txamqp resteasy root rootplot solr spark thrift wildfly -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its trac instance: https://fedorahosted.org/rel-eng/ The sources of this script can be found at: https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py -- Dan Callaghan dcall...@redhat.com Software Engineer, Products Technologies Operations Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: erlang-jsx about to be retired (Re: Orphaned Packages in rawhide (2015-04-20))
This was intended for erlang@ not devel@, I will resend it there. My apologies for the noise. -- Dan Callaghan dcall...@redhat.com Software Engineer, Products Technologies Operations Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Beaker in Fedora infra ansible
Looking at the Fedora infra ansible git repo, it seems like there is a skeleton for managing beaker01.qa.fedoraproject.org, but just the system and OS, not the Beaker application itself. (Unless I missed something?) I'd like to try and contribute a patch for Beaker server/lab controller roles. Where is the preferred place to iterate on that? Is there an open Phab issue, or should I just mail this list, or something else? I'm sure it will take me quite a few attempts to get right :-) since I haven't done anything with Fedora infra ansible before. -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: [EPEL-devel] Python 3 discussion
Excerpts from Bohuslav Kabrda's message of 2015-03-02 22:17 +10:00:
- Original Message -
Excerpts from Bohuslav Kabrda's message of 2015-03-02 21:59 +10:00:
- Original Message -
Under the current proposal every package with Python 3 dependencies
would have to depend on a specific python3x-* package, so then it would
be up to the maintainers of all those packages to manually bump their
Requires from python34-* to python35-* at some point. Which, now that
I think about it, is not that great. Even worse, if any packages form
a transitive dependency chain then *all* packages in the chain have to
update their Requires at the same time to avoid having a mix of
python34-* and python35-* requirements.
Not really. The requires/buildrequires should be in form of
Requires: python%{python3_pkgversion}-six
so when we change %python3_pkgversion in the minimal buildroot,
maintainer just rebuilds and gets updated requires.
Hmm okay. I didn't realise this.
So that means that:
* Fedora specfiles can't be used unchanged (they will require python3-*,
needs to have %{python3_pkgversion} macro inserted)
True, but note that we'll make %python3_pkgversion macro available
also in Fedora (always defined to 3), so once this change is done,
it'll be possible to have the same specfile both in Fedora and EPEL.
Okay that's good.
* applications will need to be rebuilt to pick up a change from
python34-* to python35-*
which is a bit unfortunate.
Is there any reason why we shouldn't just upgrade applications to the
python35-* stack straight away, by providing python3-*?
Yeah. First of all, it may happen that there are some minor backwards
incompatibilities. Lots of packages run tests during buildtime, so
these will be caught.
Another reason is that there are applications, which store files in
/usr/lib/python3.X/site-packages - these need to be rebuilt anyway,
since they have the Python minor version incorporated in path of
files.
I really think that we should rebuild applications with new Python
3.X.
Well, they should really be using pkg_resources instead of hardcoding
the path... but yes I take your point. Rebuilding for the newer Python
stack makes sense.
We will need to make sure that setuptools-generated entry points have
a shebang of /usr/bin/python3.4 rather than just /usr/bin/python3
though, so that the scripts are always invoked with the same Python
stack they are built for. Currently on Fedora they have
/usr/bin/python3. This might need a patch to
setuptools/distutils/whatever it is?
--
Dan Callaghan dcall...@redhat.com
Software Engineer, Hosted Shared Services
Red Hat, Inc.
signature.asc
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Python 3 discussion
Excerpts from Bohuslav Kabrda's message of 2015-03-02 21:59 +10:00:
- Original Message -
Under the current proposal every package with Python 3 dependencies
would have to depend on a specific python3x-* package, so then it would
be up to the maintainers of all those packages to manually bump their
Requires from python34-* to python35-* at some point. Which, now that
I think about it, is not that great. Even worse, if any packages form
a transitive dependency chain then *all* packages in the chain have to
update their Requires at the same time to avoid having a mix of
python34-* and python35-* requirements.
Not really. The requires/buildrequires should be in form of
Requires: python%{python3_pkgversion}-six
so when we change %python3_pkgversion in the minimal buildroot,
maintainer just rebuilds and gets updated requires.
Hmm okay. I didn't realise this.
So that means that:
* Fedora specfiles can't be used unchanged (they will require python3-*,
needs to have %{python3_pkgversion} macro inserted)
* applications will need to be rebuilt to pick up a change from
python34-* to python35-*
which is a bit unfortunate.
Is there any reason why we shouldn't just upgrade applications to the
python35-* stack straight away, by providing python3-*?
--
Dan Callaghan dcall...@redhat.com
Software Engineer, Hosted Shared Services
Red Hat, Inc.
signature.asc
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Python 3 discussion
Excerpts from Orion Poplawski's message of 2015-02-28 04:36 +10:00:
all python34 packages are retired
Except there is no way to retire an individual subpackage, is there?
Instead we are saying, the python34-* subpackage will just go away.
What I still don't understand is what this looks like on the user end,
how do they go from 34 to 35? For app users (#!/usr/bin/python3), it
seems like this should be as automatic as possible. So shouldn't they
still use /usr/bin/python3 rather than /usr/bin/python3X so they get
updated automatically?
What about all of the old python34 packages left on their systems
after retirement? Is there some way they can get cleaned up
automatically?
Well I guess normally when a subpackage goes away (because it is being
renamed or subsumed into some other package) the replacement would add
Provides and Obsoletes to handle the upgrade path.
But I don't think we want the python35-* packages to Provide/Obsolete
the python34-* packages because then everyone will be automatically
upgraded to the 3.5 stack as soon as it appears, in which case why are
we even bothering with python3x-* at all?
Under the current proposal every package with Python 3 dependencies
would have to depend on a specific python3x-* package, so then it would
be up to the maintainers of all those packages to manually bump their
Requires from python34-* to python35-* at some point. Which, now that
I think about it, is not that great. Even worse, if any packages form
a transitive dependency chain then *all* packages in the chain have to
update their Requires at the same time to avoid having a mix of
python34-* and python35-* requirements.
So we probably need to make the python3x-* subpackages provide python3-*
= %{version}-%{release}. Maybe Bohuslav already had this in mind, but
it's not mentioned on the proposal page. So then packages would just
require python3-* as they do in Fedora, and when the python35-* stack
appears yum/dnf would just automatically upgrade. The /usr/bin/python3
symlink means that everything will just keep working for applications.
On the other hand, if someone has explicitly installed a library (yum
install python34-requests), for example because they are developing
against it, then I guess they will left with the 3.4 build forever. It
is up to them to install python35-requests if/when they are ready.
--
Dan Callaghan dcall...@redhat.com
Software Engineer, Hosted Shared Services
Red Hat, Inc.
signature.asc
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: New Upstream Release Monitoring Systems
Excerpts from Ralph Bean's message of 2015-02-21 06:36 +10:00: I'm proud to announce that the Infrastructure team has finished deploying the first iteration of our replacement for the older, wiki-based Upstream Release Monitoring tools this week. You can read about the details of the trio of systems[1] now used to coordinate upstream release monitoring on the same old wiki page. Nice work, this is looking great! Is there any easy way I can check which of my packages *doesn't* yet have a valid mapping in Anitya, aside from checking each one by hand in the web UI? I want to enable release monitoring on all my packages but I've lost track of which ones were correctly configured on the old wiki page. Also, will Anitya warn me somehow if a configuration becomes invalid later (because upstream changed their hosting or similar)? -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Beaker instance
Hi Honza, Excerpts from Honza Horak's message of 2015-02-13 00:44 +10:00: Hi Dan, I missed your workshop at DevConf unfortunately, but as one of the members of Env Stacks Working Group I'm wondering what is the current status of beaker instance [1], since the wiki page [2] seems to be quite short. Is it available for some testing already? Is there any doc how to use it as I'm ordinary fedora packager (I was not able to log in)? Tim Flink and the Fedora QA team have been working on deploying Beaker in Fedora, so they are best able to answer this. Currently there is no way for regular Fedora contributors to log in, it's just username+password accounts created by Tim by hand. The plan is to use mod_auth_openid pointing as FASOpenID with some group restrictions enforced, but that needed some support on the FASOpenID side to expose Fedora group info. I guess that will be covered as part of the Ipsilon upgrade coming sometime soon. There is also an issue with the LC hostname in log URLs which we are working on. I'm also not sure what is it's use case actually. Is it generally providing a virtual machine for any use case or just for some special type of work? The initial use case was to run installer tests: https://bitbucket.org/fedoraqa/fedora-beaker-tests There has also been some interest in using Beaker to make non-x86 arches available to packagers who might need them temporarily for porting purposes. That's something we would look at once Beaker is fully up and running. I expect Tim will want to discourage the use of Beaker for just give me an x86 VM to play with scenarios, because there are other tools for that, and Fedora Beaker's hardware pool will be fairly limited. Btw. I'm also thinking about some fedora proposal for being able to store some arbitrary tests in Fedora (basically some best practices how to write tests above unit tests; written in anything, including beakerlib). Is this something you care about or is this something totally irrelevant for beaker instance? Yes I think Tim is very interested in the idea of package integration tests, which may include running jobs in Beaker. I'll let him elaborate further. -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Orphaning lua-sec, lua-dbi and prosody
Excerpts from Haïkel's message of 2015-01-23 11:46 +10:00: FYI, Prosody needs to be ported to Lua 5.2 (and we're updating to 5.3). It will either require patching Prosody and some dependencies or provide lua compatibility packages. We already have Lua 5.1 compat packages for Prosody in F21+, right? Or is something else needed? -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning lua-sec, lua-dbi and prosody
Excerpts from Johan Cwiklinski's message of 2015-01-17 03:39 +10:00: I've orphaned lua-sec, lua-dbi and prosody packages. Feel free to take ownership of those ones. Jan, I see that you are a comaintainer of prosody already and have helped with updates before. Would you be willing to take these packages from Johan? I can join as comaintainer too if you need help. I run Prosody at home so I'm keen to see it maintained. -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7
Is the EPIC proposal totally dead? It seems like that would be a nicer and more general solution to this problem (not wanting to ship a Python 3.x stack for 10 years). Personally I am not looking forward to maintaining more branches and/or (sub-)packages for every python3X-*. -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
taking python-elixir (was Re: Some orphaned packages)
Excerpts from Toshio Kuratomi's message of 2014-08-15 03:01 +10:00: python-elixir = (orphan Fedora devel, Fedora 21, Fedora 20, Fedora 19, Fedora EPEL 5) I will take this one, in order to keep the TurboGears1 stack alive. If anyone is actually using it, or is interested in helping maintain it, please get in touch with me. -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
I was just looking through the list of packages which Toshio retired: Excerpts from Toshio Kuratomi's message of 2014-06-17 05:01:26 +1000: == Packages to be orphaned retired == * python-cherrypy2 * python-elixir * python-peak-rules * python-turbocheetah * bodhi * python-tgcaptcha2 * python-turboflot * python-turbokid (need to remove a spurious dep on this from TurboGears2) * python-turbojson (need to remove a spurious dep on this from TurboGears2) * python-paste-script (this one has other dependents in Fedora but none in EPEL7. Please speak up or revive this later if you're interested) I think the only ones out of these which we need for Beaker (unless I have missed some transitive deps) are: * python-cherrypy2 * python-elixir * python-peak-rules * python-turbokid * python-turbojson * python-turbocheetah * python-paste-script Jacky, will that be enough for you? I'm a little confused now though... I would have also expected these other TG1 pieces to be on the list: * python-TurboMail * python-tgmochikit * TurboGears but it looks like they are not retired... Toshio, is there some reason you left them out? -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
Excerpts from Zhiwei Zhu's message of 2014-07-11 09:31:37 +1000: Thanks. Understand the situation now. Will discuss with my lead about the possibility to maintain the packages by ourselves. BTW, as we don't have experience of maintaining packages on epel, we have no idea how much effort will be required to do that or how difficult it would be. Could you help to share something about this? I understand that there is some kind of co-maintainer path to take for new maintainers but don't how to start it. I had hoped we would have Beaker ported off TG1 long before now, and I was going to use the retirement of the EPEL7 TG1 stack as extra motivation to get it done, but realistically we will be depending on it for quite a while still, just like you Zhiwei. So I can maintain the TG1 stack in EPEL7. I will start the un-retiring process for all the packages we need and post the exact list here. Zhiwei, if you would like to co-maintain that would be a great help. I'm not able to sponsor you into the packager group, but I think you can be a co-maintainer without a sponsor (actually I'm not sure about that...) -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
python-nose-progressive changed license: GPL to MIT
In its latest bug fix release (1.5.1), python-nose-progressive was relicensed from GPL to MIT. This version is now in rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=514208 I will push updates for F19 and F20 soon. Since this is a leaf package and it has a changed to a more permissive license, I don't see any problems. -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Beaker 0.16 released
Folks, I just wanted to let you know that we released Beaker 0.16.0 this week. This includes the fix for password hashing, which was one of the outstanding security issues with having a public Beaker deployment. https://beaker-project.org/docs/whats-new/release-0.16.html#password-hashes-use-a-more-secure-salted-form I can upgrade the Beaker instance at dev.fedoraproject.org (Tim sponsored me into the sysadmin-qa group so that I can help with this stuff). I'll do that early next week unless there are any objections. There will be a brief outage for database upgrades but I don't think that matters given that the Beaker instance is currently not usable :-) (Tim, when you can spare a few minutes please ping me and we can sort out the remaining issues with those Beaker VMs.) -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Sshd getting 'dyntransition' AVC's in SElinux enforcing mode
Excerpts from Daniel J Walsh's message of 2014-01-03 01:46:44 +1000: This is caused by sshd running with the wrong label, It should be running as sshd_t not init_t. If the executable labeled sshd_exec_t? ls -lZ /usr/sbin/sshd restorecon -v /usr/sbin/sshd should fix the label. I started getting the same AVC denials a week or so ago. My /usr/sbin/sshd was indeed wrongly labelled: $ ll -Z /usr/sbin/sshd -rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0 /usr/sbin/sshd $ sudo restorecon -v /usr/sbin/sshd restorecon reset /usr/sbin/sshd context unconfined_u:object_r:bin_t:s0-unconfined_u:object_r:sshd_exec_t:s0 What I'm wondering is, how did it become wrongly labelled? Nothing else on my filesystem was wrong, according to restorecon. The errors only appear in my logs after sshd was restarted on 24 Feb for a yum upgrade. The updated packages included: selinux-policy-3.12.1-122.fc20.noarch openssh-server-6.4p1-3.fc20.x86_64 (among many others). Any hints on how I can figure out what went wrong with the labelling of /usr/sbin/sshd? -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sshd getting 'dyntransition' AVC's in SElinux enforcing mode
Excerpts from Dan Callaghan's message of 2014-03-06 16:43:26 +1000: Excerpts from Daniel J Walsh's message of 2014-01-03 01:46:44 +1000: This is caused by sshd running with the wrong label, It should be running as sshd_t not init_t. If the executable labeled sshd_exec_t? ls -lZ /usr/sbin/sshd restorecon -v /usr/sbin/sshd should fix the label. I started getting the same AVC denials a week or so ago. My /usr/sbin/sshd was indeed wrongly labelled: $ ll -Z /usr/sbin/sshd -rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0 /usr/sbin/sshd $ sudo restorecon -v /usr/sbin/sshd restorecon reset /usr/sbin/sshd context unconfined_u:object_r:bin_t:s0-unconfined_u:object_r:sshd_exec_t:s0 What I'm wondering is, how did it become wrongly labelled? Nothing else on my filesystem was wrong, according to restorecon. The errors only appear in my logs after sshd was restarted on 24 Feb for a yum upgrade. The updated packages included: selinux-policy-3.12.1-122.fc20.noarch openssh-server-6.4p1-3.fc20.x86_64 (among many others). Any hints on how I can figure out what went wrong with the labelling of /usr/sbin/sshd? Oh, I forgot that the yum upgrade on 24 Feb was actually from F19-F20, just like Philip who originally started this thread. I suppose that means we just write it off as upgrading between releases is not supported then... -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review Swaps for sugar activities
Excerpts from Jason L Tibbitts III's message of Mon Jul 02 07:38:40 +1000 2012: DC == Dan Callaghan dcall...@redhat.com writes: DC I will take all three (they look straightforward :-) in exchange for DC saslwrapper: Since you appear to be familiar with sugar, is there any possibility that you (or anyone else who is familiar with sugar stuff) could cast a glance at https://bugzilla.redhat.com/show_bug.cgi?id=708663 ? This poor guy has been waiting for nearly 13 months for someone to look at his package. I can do the bulk of the review and the sponsorship if no sponsor/sugar expert is available but I don't know how to actually do any testing of sugar-related things. I am by no means a Sugar expert. I didn't know anything about it until I took these three reviews last night. :-) I am working from the Sugar activity guidelines here: https://fedoraproject.org/wiki/Packaging/SugarActivityGuidelines and I installed F17 in a VM and did yum groupinstall Sugar\ Desktop\ Environment for testing out the packages. It also helps that the activities are in Python which I am well versed in. As it happens I was planning to try and track down somebody responsible for those guidelines, because there are a few things which do not seem right to me. I've found the OLPC list (cc'ed) which seems to be the closest we have to a Sugar SIG. Hopefully somebody there can help out. * The sample spec in the guidelines uses Group: Sugar/Activities, but it's not mentioned anywhere else that I can find, and rpmlint complains because it is non-standard. Are we supposed to just waive that warning in the package review? * The upstream-supplied setup.py for these three Sugar activities just calls sugar.activity.bundlebuilder.start(), which seems to copy the entire directory contents wholesale into /usr/share/sugar/activities -- including stuff like setup.py, NEWS, COPYING... There are apparently a lot of existing packages that do it too: $ repoquery -f /usr/share/sugar/activities/\*/setup.py | wc -l 68 Is it really necessary to include these files in the activity directory? COPYING, NEWS, etc are already installed by %doc, as they should be, so it seems superfluous to have them installed again. And setup.py shouldn't be needed for an installed package. Should this sugar.activity.bundlebuilder be patched to be more selective in what it copies? Or should each activity package be responsible for cleaning out its buildroot after the bundlebuilder has run? Or is there some reason why these files should be installed in the activity directory? -- Dan Callaghan dcall...@redhat.com signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Swaps for sugar activities
Excerpts from Kalpa Welivitigoda's message of Sat Jun 30 18:07:07 +1000 2012: Hi, I have packaged three sugar activities and I would like for review swaps. sugar-nutrition: https://bugzilla.redhat.com/show_bug.cgi?id=823234 sugar-recall: https://bugzilla.redhat.com/show_bug.cgi?id=823236 sugar-locosugar: https://bugzilla.redhat.com/show_bug.cgi?id=836708 I will take all three (they look straightforward :-) in exchange for saslwrapper: https://bugzilla.redhat.com/show_bug.cgi?id=828626 -- Dan Callaghan dcall...@redhat.com signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
