Re: To someone with power to push packages on Fedora 21
Zbigniew Jędrzejewski-Szmek wrote: > Seriously? When I push out an update to testing, I already have done the > tests on it in my system, and it *think* it is correct. What would be > the point of pushing out something that is known to be broken? > > The time in testing is for others to others to do the same. The result > is that the push to stable is based on acks from the maintainer's + n > independent people. You seem to be saying that the maintainer's checks > alone are better. The maintainer is of course supposed to look at the testers' feedback when making the decision. But it is never a good idea to blindly trust an ill- defined integer (the difference # positive comments - # negative comments, which is only vaguely correlated to the quality of the update) going above an arbitrary threshold. It makes a difference who the testers are and what exactly they wrote! The software simply CANNOT make that call for you. Kevin Kofler -- 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: ansible in Fedora 23+ (python3)
Fabio Alessandro Locati wrote: > Also, the problem is that RedHat still supports RHEL5 systems which > for today standards are totally legacy and therefore it has to run on > Python 2.4. The point of forking would be that the fork wouldn't have to care. Let the upstream project deal with ancient legacy systems, the rest of the world can and should move on. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 23 Final blocker status #1
Hi folks! Time for a blocker status mail - well, past time, but I hadn't found time to do one till now. Status is that Go/No-Go is on Thursday: we really need an RC1 by tomorrow in order to have sufficient testing time. Action summary: Blocker reviewers - Review: * https://bugzilla.redhat.com/show_bug.cgi?id=1273102 * https://bugzilla.redhat.com/show_bug.cgi?id=1273167 QA -- Test proposed fixes: * https://bugzilla.redhat.com/show_bug.cgi?id=1262600 (kickstart change, must spin live image to test) * https://bugzilla.redhat.com/show_bug.cgi?id=1261569 (updates.img for testing against TC9) Developers (inc. releng) Fix: * https://bugzilla.redhat.com/show_bug.cgi?id=1263677 (wwoods, dnf-plugin-system-upgrade) * https://bugzilla.redhat.com/show_bug.cgi?id=1268802 (releng, fedora-repos / fedora-release?) * https://bugzilla.redhat.com/show_bug.cgi?id=1271061 (plautrba, setroubleshoot) Possibly fix (proposed blockers): * https://bugzilla.redhat.com/show_bug.cgi?id=1273102 (nmavrogi et al., gnutls) * https://bugzilla.redhat.com/show_bug.cgi?id=1273167 (lrintel, NetworkManager) Here's the blow-by-blow on proposed and approved blockers: Accepted 1. https://bugzilla.redhat.com/show_bug.cgi?id=1261569 - anaconda "old kernel boots by default after upgrade" We have a fix for this that's had a bit of testing, but could do with more. To test, install TC9 with the updates.img and then update the kernel, and check the new kernel is listed in 'grub2-editenv list' output (and that it's the default choice on reboot). 2. https://bugzilla.redhat.com/show_bug.cgi?id=1263677 - dnf-plugin-system-upgrade "it's very easy to end up with a partially-upgraded system" This is kind of a catch-all bug for the behaviour changes requested to DNF and dnf-plugin-system-upgrade by FESCo. wwoods is working on this one (after being out sick for a few days), we're expected a new build of dnf-plugin-system-upgrade soon. I believe this can be considered a 'special blocker' - i.e. it does not block the f23 image compose, instead it must be pushed as an F21 and F22 update before F23 release day. 3. https://bugzilla.redhat.com/show_bug.cgi?id=1268802 - fedora-repos "updates-testing is still enabled for Fedora 23" This is just a request for the fedora-repos build that disables updates-testing. We usually do this without a blocker bug, and there's nothing difficult about it, releng will be doing it when we're nearly ready for RC1. 4. https://bugzilla.redhat.com/show_bug.cgi?id=1271061 - setroubleshoot "[abrt] setroubleshoot-server: g_callable_info_free_closure(): python3.4 killed by SIGSEGV" This is a fairly newly-prioritized one, the SELinux alert browser GUI is not really working right since its python3 port. The devs are looking into it but we don't have a solid cause yet. Needs dev work. 5. https://bugzilla.redhat.com/show_bug.cgi?id=1262600 - spin-kickstarts "Plasma live session notifies for available updates" This is just as described in the summary. KDE team has just come up with a possible patch and I'll be testing it shortly. Proposed 1. https://bugzilla.redhat.com/show_bug.cgi?id=1273102 - gnutls "Gnutls Servers (eg: cockpit) fail fallback with Google Chrome 46" This is a bad behaviour in TLS init in gnutls which unfortunately breaks access to the Cockpit UI on Server installs from recent Chrome/Chromium builds. It seems like we're fairly clear on the cause of this now and we have to make a call on how much of a blocker it is; it would be great if devs could work on a fix in case it is decided to be a blocker. 2. https://bugzilla.redhat.com/show_bug.cgi?id=1273167 - NetworkManager "ipv4.ignore-auto-dns=yes isn't honored" The potential blocker issue here is that it seems you can't override the DNS server used in anaconda by just passing a single parameter as you should be able to, it seems you have to pass a whole static config to dracut to avoid the DHCP-provided name server being the default. This is a pain if you need to use a different DNS server for registering with a FreeIPA / AD domain. sgallagh and I are reasonably familiar with this scenario and our tentative take is that in most production cases the DHCP-provided DNS server should support realm discovery so it probably doesn't need to be a blocker, but we do want to confirm that domain registration works in that case, and other thoughts would be welcome. It would certainly be good if NM devs could look at the problem here too. Thanks everyone! It's looking pretty tight to get the release signed off this week, but we'll do our best. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.
Re: Fedora 23 Final blocker status #1
On Mon, 2015-10-19 at 17:03 -0700, Adam Williamson wrote: > Hi folks! Time for a blocker status mail - well, past time, but I > hadn't found time to do one till now. Small addendum - I've added one more proposed blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1273214 - spin-kickstarts "Build final F23 spin-kickstarts package" This is just another fairly process-y thing that needs doing, various of us can do it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unresponsive maintainer: patches
2015-10-19 13:00 GMT+02:00 Viktor Jancik : > Hi, > > As per the Policy for nonresponsive package maintainers: > https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > > I am writing here to ask you, if any of you know how to get in contact with > T.C. Hollingsworth? > > It appears he has been inactive for +6 months and I to contact him about some > of his packages. > > Thank you, > Viktor > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Please re-read the policy, you're one week too early. And if you want to update npm, you could also request ACLs. Regards, H. -- 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: Heads Up: New pugixml coming to rawhide
On Mon, Oct 19, 2015 at 3:11 PM, Nicolas Chauvet wrote: > Thx for the update. > Can you verify that "long long" is enabled by default in the fedora build > (as it should per this https://github.com/zeux/pugixml/issues/53 report) > > This will help me to switch filezilla to pugixml. > I can confirm the cmake code in the referenced commit is there but it appears to be dependent on cmake 3.1+. I'm assuming you don't need this on Fedora 21 or EPEL, correct? Thanks, Richard -- 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: Heads Up: New pugixml coming to rawhide
2015-10-19 20:46 GMT+02:00 Richard Shaw :
> In the next couple of days I'll be doing an update of pugixml in rawhide.
> The affected packages seem to be:
>
> # repoquery --qf=%{name} --repoid=rawhide --whatrequires --source
> "libpugixml.so.1()(64bit)"
> OpenImageIO-1.5.20-1.fc24.src.rpm
> OpenImageIO-1.5.20-1.fc24.src.rpm
> OpenImageIO-1.5.20-1.fc24.src.rpm
> fts-3.3.1-3.fc24.src.rpm
> fts-3.3.1-3.fc24.src.rpm
> fts-3.3.1-3.fc24.src.rpm
> gfal2-2.9.3-1.fc23.src.rpm
> mkvtoolnix-8.4.0-1.fc24.src.rpm
> mkvtoolnix-8.4.0-1.fc24.src.rpm
> orthanc-0.8.6-6.fc24.src.rpm
> orthanc-0.8.6-6.fc24.src.rpm
> paraview-4.4.0-1.fc24.src.rpm
> paraview-4.4.0-1.fc24.src.rpm
> paraview-4.4.0-1.fc24.src.rpm
> pugixml-1.6-2.fc23.src.rpm
>
> I'm not sure why --qf isn't working..
>
> I'll take care of OpenImageIO.
>
> Thanks,
> Richard
>
Thx for the update.
Can you verify that "long long" is enabled by default in the fedora build
(as it should per this https://github.com/zeux/pugixml/issues/53 report)
This will help me to switch filezilla to pugixml.
thx
--
-
Nicolas (kwizart)
--
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: Announcing the release of Fedora 23 Beta!
2015-10-19 20:47 GMT+02:00 Reindl Harald : > > > Am 19.10.2015 um 20:35 schrieb Gerard Ryan: >> >> On 10/18/2015 06:49 PM, Andreas Tunek wrote: >>> >>> I still can't upgrade, I get: >>> >>> dnf system-upgrade download --releasever=23 --distro-sync >>> dnf system-upgrade reboot >> >> >> Yes, I'm in the same situation. Would you mind adding the info of what >> you get to the bug in bugzilla so that the maintainers can see it all in >> one place (it's difficult for everyone to keep up with this mailing list >> all the time) and know that there are more people experiencing it > > > any bet "dnf --releasever=23 --distro-sync" followed by a reboot just works > as online dist-upgrades are working *for years* on dozens fo machines while > all the offline-updatem, pre-upgrade and whatever stuff was *never* > reliebale > > I am trying to test the supported way of doing things. There are a zillion other ways to it (on the computer I am typing now I have to do a reinstall due to https://bugzilla.redhat.com/show_bug.cgi?id=1270953), but here I want to test the supported upgrade route. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Heads Up: New pugixml coming to rawhide
On Mon, Oct 19, 2015 at 2:17 PM, Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > Feel free to bump&rebuild mkvtoolnix. I'm planning an update to 8.5.0, > but I don't know if I'll be able to do it in time. Is there a new > pugixml build I can test against? I probably need to go ahead and get provenpackager access :) I can setup a scratch build if it helps but only one symbol was removed... https://dl.dropboxusercontent.com/u/34775202/compat_reports/pugixml/1.6_to_1.7/compat_report.html Thanks, Richard -- 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: Heads Up: New pugixml coming to rawhide
Hi!
On Monday, 19 October 2015 at 20:46, Richard Shaw wrote:
> In the next couple of days I'll be doing an update of pugixml in rawhide.
Thanks for the heads-up.
> The affected packages seem to be:
>
> # repoquery --qf=%{name} --repoid=rawhide --whatrequires --source
> "libpugixml.so.1()(64bit)"
[...]
> mkvtoolnix-8.4.0-1.fc24.src.rpm
[...]
Feel free to bump&rebuild mkvtoolnix. I'm planning an update to 8.5.0,
but I don't know if I'll be able to do it in time. Is there a new
pugixml build I can test against?
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
--
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: Announcing the release of Fedora 23 Beta!
On 10/19/2015 07:47 PM, Reindl Harald wrote: > > > Am 19.10.2015 um 20:35 schrieb Gerard Ryan: >> On 10/18/2015 06:49 PM, Andreas Tunek wrote: >>> I still can't upgrade, I get: >>> >>> dnf system-upgrade download --releasever=23 --distro-sync >>> dnf system-upgrade reboot >> >> Yes, I'm in the same situation. Would you mind adding the info of what >> you get to the bug in bugzilla so that the maintainers can see it all in >> one place (it's difficult for everyone to keep up with this mailing list >> all the time) and know that there are more people experiencing it > > any bet "dnf --releasever=23 --distro-sync" followed by a reboot just > works as online dist-upgrades are working *for years* on dozens fo > machines while all the offline-updatem, pre-upgrade and whatever stuff > was *never* reliebale Thankfully I only ever have one or two systems to update. :) Even if that online way that you mention works, I'm going to hold off until the "recommended" (is it?) way works, since otherwise I won't have any way to verify the fix when it comes. Let's hope that once these issues are ironed out that it will be as reliable as any other way. -- 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: Announcing the release of Fedora 23 Beta!
Am 19.10.2015 um 20:35 schrieb Gerard Ryan: On 10/18/2015 06:49 PM, Andreas Tunek wrote: I still can't upgrade, I get: dnf system-upgrade download --releasever=23 --distro-sync dnf system-upgrade reboot Yes, I'm in the same situation. Would you mind adding the info of what you get to the bug in bugzilla so that the maintainers can see it all in one place (it's difficult for everyone to keep up with this mailing list all the time) and know that there are more people experiencing it any bet "dnf --releasever=23 --distro-sync" followed by a reboot just works as online dist-upgrades are working *for years* on dozens fo machines while all the offline-updatem, pre-upgrade and whatever stuff was *never* reliebale signature.asc Description: OpenPGP digital 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
Heads Up: New pugixml coming to rawhide
In the next couple of days I'll be doing an update of pugixml in rawhide.
The affected packages seem to be:
# repoquery --qf=%{name} --repoid=rawhide --whatrequires --source
"libpugixml.so.1()(64bit)"
OpenImageIO-1.5.20-1.fc24.src.rpm
OpenImageIO-1.5.20-1.fc24.src.rpm
OpenImageIO-1.5.20-1.fc24.src.rpm
fts-3.3.1-3.fc24.src.rpm
fts-3.3.1-3.fc24.src.rpm
fts-3.3.1-3.fc24.src.rpm
gfal2-2.9.3-1.fc23.src.rpm
mkvtoolnix-8.4.0-1.fc24.src.rpm
mkvtoolnix-8.4.0-1.fc24.src.rpm
orthanc-0.8.6-6.fc24.src.rpm
orthanc-0.8.6-6.fc24.src.rpm
paraview-4.4.0-1.fc24.src.rpm
paraview-4.4.0-1.fc24.src.rpm
paraview-4.4.0-1.fc24.src.rpm
pugixml-1.6-2.fc23.src.rpm
I'm not sure why --qf isn't working..
I'll take care of OpenImageIO.
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 23 Branched 20151019 compose check report
No missing expected images. Images in this compose but not 23 Branched 20151018: Cloud docker x86_64 Design_suite live x86_64 Design_suite live i386 No images in 23 Branched 20151018 but not this. Failed openQA tests: 9 of 52 ID: 6642Test: i386 kde_live default_install ID: 6640Test: x86_64 kde_live default_install ID: 6634Test: i386 universal upgrade_desktop_32bit ID: 6625Test: x86_64 universal server_no_swap@uefi ID: 6624Test: x86_64 universal server_lvmthin@uefi ID: 6619Test: x86_64 universal server_simple_free_space@uefi ID: 6617Test: x86_64 universal server_delete_partial@uefi ID: 6615Test: x86_64 universal server_sata_multi@uefi ID: 6610Test: x86_64 universal upgrade_desktop_64bit Passed openQA tests: 43 of 52 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- 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: Announcing the release of Fedora 23 Beta!
On 10/18/2015 06:49 PM, Andreas Tunek wrote: > 2015-10-02 21:20 GMT+02:00 Gerard Ryan : >> On 10/02/2015 07:11 PM, Andreas Tunek wrote: >>> 2015-09-26 0:10 GMT+02:00 Thomas Daede : On 09/25/2015 02:18 PM, Andreas Tunek wrote: > Removed librtmp (what could go wrong?), now I get the following error: > > Sep 25 23:14:39 iMacLinux dnf[621]: Error: package > kernel-core-4.1.7-200.fc22.x86_64 requires systemd >= 200, but none of > the providers can be installed > Sep 25 23:14:39 iMacLinux dnf[621]: (try to add '--allowerasing' to > command line to replace conflicting packages) > Sep 25 23:14:39 iMacLinux systemd[1]: dnf-system-upgrade.service: main > process exited, code=exited, status=1/FAILURE > Sep 25 23:14:39 iMacLinux systemd[1]: Unit dnf-system-upgrade.service > entered failed state. > Sep 25 23:14:39 iMacLinux systemd[1]: dnf-system-upgrade.service failed. > Sep 25 23:14:39 iMacLinux systemd[1]: Rebooting as result of failure. > This looks like it might be related to https://bugzilla.redhat.com/show_bug.cgi?id=1244175 I had a similar problem. --allowerasing will try to erase the currently running kernel, which will fail. >>> >>> Seems like the above is a blocker now. I will test again when updated. >>> >> >> FWIW I think you're hitting the same issue as I am, reported here: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1266589 >> >> -- > > I still can't upgrade, I get: > > dnf system-upgrade download --releasever=23 --distro-sync > dnf system-upgrade reboot > > ... > Oct 18 19:45:47 iMacLinux dnf[668]: Error: package > kernel-core-4.2.3-200.fc22.x86_64 requires systemd >= 200, but none of > the providers can be installed > Oct 18 19:45:47 iMacLinux dnf[668]: (try to add '--allowerasing' to > command line to replace conflicting packages) > Oct 18 19:45:47 iMacLinux systemd[1]: dnf-system-upgrade.service: main > process exited, code=exited, status=1/FAILURE > Oct 18 19:45:47 iMacLinux systemd[1]: Unit dnf-system-upgrade.service > entered failed state. > Oct 18 19:45:47 iMacLinux systemd[1]: dnf-system-upgrade.service failed. > Oct 18 19:45:47 iMacLinux systemd[1]: Rebooting as result of failure. > Oct 18 19:45:47 iMacLinux audit[1]: pid=1 uid=0 > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 > msg='unit=dnf-system-upgrade comm="systemd" exe= > ... Hi Andreas, Yes, I'm in the same situation. Would you mind adding the info of what you get to the bug in bugzilla so that the maintainers can see it all in one place (it's difficult for everyone to keep up with this mailing list all the time) and know that there are more people experiencing it. Thanks a lot, Gerard. -- 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: Recommended way of proposing changes in someone else Fedora packages configuration
On Mon, Oct 19, 2015 at 9:42 AM Jared K. Smith wrote: > On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski wrote: > >> I like the idea with mirroring Fedora Git to GitHub. Read only mirror >> just to be a dedicated place for that kind of contributions (via pull >> requests). >> > > While I like the idea of making it easier for people to submit patches, > I'm not sure setting up a read-only GitHub mirror is the answer. > > In my day job, I happen to maintain a huge GitHub mirror of a large open > source code repository where the upstream has not yet moved to Git. > Unfortunately, what happens is that people submit pull requests against the > read-only mirror, but the upstream maintainers rarely if ever look at the > pull requests. We end up closing most of the pull requests with a message > that says "Contact upstream directly and try to get your patches to them." > > The ASF uses a pubsub bot to notify project's devel mailing lists when a PR is issued against the read-only mirrors on GitHub. This email contains instructions on how to add a second remote and perform the pull request manually. It also explains how to force the PR to be closed without write access to the mirror (with a commit message that says something like "this closes #X", where X is the PR number, which gets processed when the mirror is next sync'd). In this way, it opens up the community to a wider audience by enabling contributors to use tools they are comfortable with, but in a way that doesn't technically add a dependency on GitHub. Fedora could do something similar by automatically opening a BZ issue, in the same way upstream monitoring opens up new BZs. I know this would be really useful, because before I submitted my first package to Fedora, I had a slightly difficult time figuring out how to contribute, or even check out and view a project's git repository (doing an anonymous clone with fedpkg wasn't obvious). > I also think it would be non-trivial to map Fedora users to GitHub > accounts, or to keep said information in sync. > > This would be non-trivial... but it's also completely unnecessary. The mirrors can/should be read-only while the Fedora repos remain authoritative, with maintainer write-access. The ASF does allow committers to affiliate with the ASF org in GitHub (where the read-only mirrors exist) by voluntarily adding their GitHub usernames to a database, but this doesn't get them any special access to the mirrors... it's just for flair, to show off their membership on their GitHub profile. As far as I'm concerned, this is a completely unnecessary thing to do. Perhaps at some point, we could do this by offering a voluntary field for GitHub username, but it's certainly not essential to using GitHub to enable pull-requests. Of course, Fedora doesn't have to do it the way the ASF did, but I think there's value in looking at what they've done, because there's value in exposing Fedora's packages to a large (and growing) community of GitHub. -- 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-legal-list] tktable license clarification
> "AT" == Antonio Trande writes: AT> Probably i taken too much seriously this "type of joke", so much AT> that this issue does not deserve any answer. Well, if the license text says "you must buy me a beer of you see me" or whatever then that would render the software non-free regardless. If it says "feel free to", "please consider", "you are strongly encouraged" or the like, then the clause does not impact the free-ness of the software. (Yes, there was some software which required users to purchase some beverage, and that software was non-free until the license was altered.) In this case, it's just a request and can be ignored. (not a lawyer, blah, blah.) I didn't read the rest of the license to see if there's anything else in there, though. - J< -- 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: Un-retiring tktable package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/17/2015 12:13 PM, Antonio Trande wrote: > On 10/17/2015 11:57 AM, Antonio Trande wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> Hi all, >> >> I wish take care of tktable package currently retired by Fedora. >> This package was retired on 2012-02-06 due to lack of a >> maintainer, also latest release came out in Nov. 2008. >> >> However, upstream maintainer says TkTable development is not >> dead confirming that current release still works with latest >> TclTk, so, I think, upstream support is still valid. >> > > New review request: > https://bugzilla.redhat.com/show_bug.cgi?id=1272652 > A review swap is valid for who wanted. - -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x565E653C Check on https://keys.fedoraproject.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWJSYVAAoJEF5tK7VWXmU8l0MH/3TjolnU7gtIvPvjtSeez2HB wxLd9l3hIOjCRe53Xu77PSaZRXSrdOxY+Vawn+dQnMFB/C9WOLTgyisrvG941nsC 8zhvpFJs6DEwa+hhakhLEgopwml3dv9TBn/B2kYG/Dq6GtywAr9qD1DaDdBRPYwE mM4P7jWWlmCUjuSd99zYPoszGG1jd0oCghqcTOzvWluZDH/If4uQ3aZxPtRlKyLS F8e13JIswTdWbqJ35QMd4ac1zL5xLubE1IQLPFLizD48qziBZ5Jiq2tWJlbSVtP3 +lkwewW/cVcUU3pyM3x55tE22JB0apAvOJNVQ/JAlyFEmEO6EQZauOq3y9k+vKc= =DsAJ -END 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: tktable license clarification
On 10/18/2015 12:55 PM, Antonio Trande wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi all, > > tktable package is newly under review; can someone clarify to me how > to identify its license? (license file attached) > > In particular, i have a doubt about these "special notes": > > * > SPECIAL NOTES: > > This software is also falls under the bourbon_ware clause v2: > > This software is free, but should you find this software useful in your > daily work and would like to compensate the author, donations in the form > of aged bourbon and scotch are welcome by the author. The user may feel > exempt from this clause if they are below drinking age or think the > author > has already partaken of too many drinks. > * > > Thanks. > > - -- > Antonio Trande > Probably i taken too much seriously this "type of joke", so much that this issue does not deserve any answer. I suppose that tktable will be released with license TCL again. -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x565E653C Check on https://keys.fedoraproject.org/ -- 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: ansible in Fedora 23+ (python3)
On Mon, Oct 19, 2015 at 4:37 AM, Fabio Alessandro Locati wrote: > 2015-10-19 2:33 GMT+02:00 Kevin Kofler : >> Dusty Mabe wrote: >>> Does anyone have a good solution for this? Obviously it would be nice >>> if ansible went to python3 but I think they have stated clearly that >>> they are sticking with python2 for backwards compat with systems that >>> still need 2.4. >> >> I don't understand why still nobody has forked Ansible to get it out of the >> stone age. > > It's not so easy. Ansible is based on Twisted which is not yet 100% > Python3 compatible, as far as I understood. > Also, the problem is that RedHat still supports RHEL5 systems which > for today standards are totally legacy and therefore it has to run on > Python 2.4. What makes you think it's based on twisted? I just did a 'git grep twisted' on the ansible code base and got zero hits. -AdamM > > -- > Fabio Alessandro Locati > > PGP Fingerprint: B960 BE9D E7A8 FA12 273A 98BB 6D6A 29D6 709A 7851 > https://keybase.io/fale > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Kernel 4.2.3-200 stability problems and mouse cursor defects...
Fedora Devel, Just wanted to get more information on a bug that bit me over the weekend. Running Fedora 22 and updated to 'kernel.x86_64 4.2.3-200.fc22'. There's no mouse cursor on the login screen at all. When logging in either on X11 or the Wayland session I repeatedly get Kernel Oops messages and the mouse cursors jumps about and appears jittery or to make duplicated copies of itself on screen. Using Fedora is very difficult and things don't appear stable or normal I get a message like this in the backtrace: [] dump_stack+0x45/0x57 [] warn_slowpath_common+0x86/0xc0 [] warn_slowpath_fmt+0x55/0x70 [] i915_gem_track_fb+0x129/0x140 [i915] [] intel_prepare_plane_fb+0xe7/0x1a0 [i915] [] drm_atomic_helper_prepare_planes+0x59/0xe0 [drm_kms_helper] [] __intel_set_mode+0x1ae/0xb60 [i915] [] ? intel_modeset_compute_config+0x3af/0xb60 [i915] [] intel_crtc_set_config+0x2b6/0x580 [i915] [] drm_mode_set_config_internal+0x66/0x100 [drm] [] drm_mode_setcrtc+0x3e9/0x500 [drm] [] drm_ioctl+0x125/0x610 [drm] [] ? avc_compute_av+0x15d/0x190 [] ? drm_mode_setplane+0x1b0/0x1b0 [drm] [] do_vfs_ioctl+0x295/0x470 [] ? selinux_file_ioctl+0x4d/0xc0 [] SyS_ioctl+0x79/0x90 [] entry_SYSCALL_64_fastpath+0x12/0x71 This appears similar to bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1241197 https://bugzilla.redhat.com/show_bug.cgi?id=1254248 Do you have further information on this? Also I am unable to log-in to Buzilla to further report this problem and have sent several reset password requests but no reset link has been sent to me. Thank you! Best, Alex G.S. -- 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: Orphaned Packages in rawhide (2015-10-19)
On 19.10.2015 17:04, opensou...@till.name wrote: [...] thinkfan orphan, madsa0 weeks ago Taken. [...] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaned Packages in rawhide (2015-10-19)
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Package(co)maintainers Status Change === autodir orphan, thias2 weeks ago boa orphan, thias2 weeks ago camE orphan, thias2 weeks ago cdargs orphan, mjakubicek 2 weeks ago crystal-clearorphan, chitlesh 1 weeks ago crystal-project orphan, chitlesh 1 weeks ago csmash orphan, thias2 weeks ago ctapi-common orphan, tmraz1 weeks ago cvs2svn orphan, mjakubicek, tremble 2 weeks ago dcliborphan, mjakubicek 2 weeks ago eclipse-ecloxorphan, chitlesh 1 weeks ago eclipse-texlipse orphan, chitlesh, mef1 weeks ago eclipse-veditor orphan, chitlesh 1 weeks ago g3data orphan, jspaleta 5 weeks ago gkrellm-aclock orphan, thias2 weeks ago gkrellm-freq orphan, thias2 weeks ago gkrellm-moon orphan, thias2 weeks ago gkrellm-sun orphan, thias2 weeks ago html-xml-utils orphan, mjakubicek 2 weeks ago i8kutils orphan, thias2 weeks ago idjc orphan, comzeradd2 weeks ago irsimorphan, chitlesh, filiperosset 1 weeks ago kde-plasma-applicationname orphan 1 weeks ago knetstatsorphan, chitlesh 1 weeks ago libtsm orphan, kwizart 5 weeks ago log4cxx orphan, mjakubicek, mtasaka 2 weeks ago mitter orphan, abbot6 weeks ago oidentd orphan, athmane, thias 1 weeks ago openct orphan, tmraz1 weeks ago openvpn-auth-ldaporphan, thias2 weeks ago opticalraytracer orphan, mjakubicek, mmahut 2 weeks ago orsa orphan, deji, mjakubicek,2 weeks ago mmahut, rakesh pidgin-epel orphan, mcepl7 weeks ago prototypeorphan 4 weeks ago pymetar orphan, thias2 weeks ago python-Coherence orphan, thias2 weeks ago python-dialogorphan, firemanxbr, 2 weeks ago mjakubicek, sundaram python-dotconf orphan, mjakubicek 2 weeks ago python-lirc orphan, thias2 weeks ago python-louie orphan, thias2 weeks ago python-nevow orphan, thias2 weeks ago python-ogg orphan, thias2 weeks ago python-tag orphan, thias2 weeks ago python-twill orphan, thias2 weeks ago python-twisted-web2 orphan, thias2 weeks ago python-vorbisorphan, thias2 weeks ago python-wikimarkuporphan, mjakubicek 2 weeks ago radiusclient-ng orphan, nmav 1 weeks ago redetorphan, rishi5 weeks ago ritopt orphan, mef 11 weeks ago rubygem-ghostorphan, madsa0 weeks ago scriptaculousorphan 4 weeks ago sfbm orphan 1 weeks ago sitecopy
Re: Recommended way of proposing changes in someone else Fedora packages configuration
On Mon, Oct 19, 2015 at 10:18:15AM -0400, Jeff Peeler wrote: > On Sun, Oct 18, 2015 at 4:00 PM, Kevin Fenzi wrote: > > I'd think a pagure.io like frontend would but at somewhat of a > > different level than this. You would: > > > > * Go to the interface and create a fork of the package you want to > > change. > > * Clone that fork and work on it locally with the normal fedpkg tools. > > * When it's set, submit a PR to the package owners with all the changes > > in your fork you want to submit. > > Using pagure would be very much a superior work flow. But basically > anything that supports handling and reviewing patches would be a big > step forward above the current bugzilla based process. This thread > reminds me of an email I sent earlier this year: > > https://lists.fedoraproject.org/pipermail/devel/2015-January/207033.html > > There I was simply yearning for a tool to help with newly introduced > packages. If Fedora can utilize a tool (such as pagure) to help with > the entire lifetime of the package, all the more better! I just wanted to let people know that: - we have a cloud instance of pagure running on the top of a (outdated) dist-git at: http://209.132.184.205/ feel free to see what's right/wrong with it and can/should be fixed Note: there is currently a problem in the way the data was loaded in the DB, so some users are not getting their packages attributed, I need to look into this and reload the DB - I created a tag for tickets/issues related to this 'project' for pagure, so feel free to look at the remaining tickets if you would like to help: https://pagure.io/pagure/issues?tags=pkgs.fp (Looking at the list now, I realize that not all the work/steps done were documented in a ticket ^^). Hope this help, Pierre -- 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 Request: vtable-dumper
On Mon, Oct 19, 2015 at 9:16 AM, Orion Poplawski wrote: > Taken. Perhaps you could take > https://bugzilla.redhat.com/show_bug.cgi?id=1262965 ? > Got it. Thanks, Richard -- 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: [389-devel] DSAdmin tests and basic functionality in the lib389
On 10/19/2015 10:02 AM, Simon Pichugin wrote:
Hi team,
I am working now on the fixing lib389 broken tests:
https://fedorahosted.org/389/ticket/48303
And it's time for dsadmin_* tests. Can anybody, please, tell me more
about it?
As I see, Mark and Thierry worked on it, but any other team
members are welcomed too. :)
I think all I did for it was to make it python 3 compliant. I think it
was a work-in-progress fora future CLI interface. Thierry can probably
answer this for sure, but it s definitely not being used at the moment.
I have a few questions:
1) What should we do with dsadmin_* tests and its coverage?
- for example, we have "TypeError: 'NoneType' object is not callable" after
- topology.conn.replica.changelog and
- topology.conn.backend.add
- or "AttributeError: DirSrv has no attribute 'getMTEntry'" after
- topology.conn.getMTEntry('o=MISSING')
And it is only a few revealed after first run.
2) Should we rename dsadmin_* tests somehow? (there is no dsadmin project
anymore)
3) Do we need bug_harness.py or is it obsolete?
Again, I think Thierry can answer these questions best.
Regards,
Mark
Please, provide me with details.
Thanks,
Simon
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Recommended way of proposing changes in someone else Fedora packages configuration
On Sun, Oct 18, 2015 at 4:00 PM, Kevin Fenzi wrote: > I'd think a pagure.io like frontend would but at somewhat of a > different level than this. You would: > > * Go to the interface and create a fork of the package you want to > change. > * Clone that fork and work on it locally with the normal fedpkg tools. > * When it's set, submit a PR to the package owners with all the changes > in your fork you want to submit. Using pagure would be very much a superior work flow. But basically anything that supports handling and reviewing patches would be a big step forward above the current bugzilla based process. This thread reminds me of an email I sent earlier this year: https://lists.fedoraproject.org/pipermail/devel/2015-January/207033.html There I was simply yearning for a tool to help with newly introduced packages. If Fedora can utilize a tool (such as pagure) to help with the entire lifetime of the package, all the more better! -- 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: To someone with power to push packages on Fedora 21
On Mon, Oct 19, 2015 at 02:45:14AM +0200, Kevin Kofler wrote: > Kevin Fenzi wrote: > > Well, we don't know for sure that those updates lost autokarma > > (Although it seems likely). It might be the maintainers pushed them > > with autokarma disabled. > > And they should have, in any case, because autokarma is just broken by > design. Who is more qualified to decide when an update should go stable? > a) the maintainer of the package or > b) some random people with no credentials beyond a FAS account > Think about it! Seriously? When I push out an update to testing, I already have done the tests on it in my system, and it *think* it is correct. What would be the point of pushing out something that is known to be broken? The time in testing is for others to others to do the same. The result is that the push to stable is based on acks from the maintainer's + n independent people. You seem to be saying that the maintainer's checks alone are better. Zbyszek -- 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 Request: vtable-dumper
On 10/19/2015 08:04 AM, Richard Shaw wrote: If someone has time for a quick review I have submitted vtable-dumper: https://bugzilla.redhat.com/show_bug.cgi?id=1273065 It is a new requirement from the same upstream for an existing package, abi-dumper: https://admin.fedoraproject.org/pkgdb/package/abi-dumper/ Thanks, Richard Taken. Perhaps you could take https://bugzilla.redhat.com/show_bug.cgi?id=1262965 ? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review Request: vtable-dumper
If someone has time for a quick review I have submitted vtable-dumper: https://bugzilla.redhat.com/show_bug.cgi?id=1273065 It is a new requirement from the same upstream for an existing package, abi-dumper: https://admin.fedoraproject.org/pkgdb/package/abi-dumper/ Thanks, Richard -- 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: To someone with power to push packages on Fedora 21
On Mon, 19 Oct 2015 15:33:38 +0200 Jan Kratochvil wrote: > There were filed and "fixed" exactly the opposite Bugs, to switch > from NVRA to the FEDORA-2015-7113eaf84e style: > RFE: use update alias/updateid instead of update title in > methods https://github.com/fedora-infra/bodhi/issues/186 > URLs should use update ID not title > https://github.com/fedora-infra/bodhi/issues/221 > > So I am not going to fight it back. But I have found - despite such > URL is not listed anywhere - one can still use the NVRA. So these > URLs are the same: > https://bodhi.fedoraproject.org/updates/FEDORA-2015-7113eaf84e > https://bodhi.fedoraproject.org/updates/gdb-7.9.1-20.fc22 Right as is: https://bodhi.fedoraproject.org/updates/FEDORA-2015-7113eaf84e/anything-at-all So, when posting a list of bodhi urls, it's best IMHO to use: https://bodhi.fedoraproject.org/updates/$UPDATEID/$packagenames so people can see what packages are mentioned. The updates-testing report already does this. kevin pgpNJ6dMdJTts.pgp Description: OpenPGP digital 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: Recommended way of proposing changes in someone else Fedora packages configuration
On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski wrote: > I like the idea with mirroring Fedora Git to GitHub. Read only mirror > just to be a dedicated place for that kind of contributions (via pull > requests). > While I like the idea of making it easier for people to submit patches, I'm not sure setting up a read-only GitHub mirror is the answer. In my day job, I happen to maintain a huge GitHub mirror of a large open source code repository where the upstream has not yet moved to Git. Unfortunately, what happens is that people submit pull requests against the read-only mirror, but the upstream maintainers rarely if ever look at the pull requests. We end up closing most of the pull requests with a message that says "Contact upstream directly and try to get your patches to them." I also think it would be non-trivial to map Fedora users to GitHub accounts, or to keep said information in sync. -- Jared Smith -- 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: Ansible 2.0 in Fedora: review request for python-shade (and a copr)
On Wed, Oct 14, 2015 at 08:35:49PM +0200, Haïkel wrote:
> Under review, thanks for preparing ansible 2.0 landing :)
Haïkel,
I think I fixed the spec file w/r/t to your initial review comments.
Cheers,
--
Lars Kellogg-Stedman | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
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: To someone with power to push packages on Fedora 21
On Sun, 18 Oct 2015 22:03:43 +0200, Kevin Fenzi wrote: > On Sun, 18 Oct 2015 21:14:25 +0200 Jan Kratochvil > wrote: > > > That is a Bug of Bodhi, the URLs should be more descriptive. > > (I have not filed it.) > > I thought it was filed, but I can't seem to find it now. ;( There were filed and "fixed" exactly the opposite Bugs, to switch from NVRA to the FEDORA-2015-7113eaf84e style: RFE: use update alias/updateid instead of update title in methods https://github.com/fedora-infra/bodhi/issues/186 URLs should use update ID not title https://github.com/fedora-infra/bodhi/issues/221 So I am not going to fight it back. But I have found - despite such URL is not listed anywhere - one can still use the NVRA. So these URLs are the same: https://bodhi.fedoraproject.org/updates/FEDORA-2015-7113eaf84e https://bodhi.fedoraproject.org/updates/gdb-7.9.1-20.fc22 Jan -- 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: New package request
On Mon, 2015-10-19 at 06:51 -0600, Kevin Fenzi wrote: > On Mon, 19 Oct 2015 12:53:39 +0200 > Marek Skalický wrote: > > > Hello everyone, > > does someone know how the "Request new package" in pkgdb works? > > (https://fedoraproject.org/wiki/PackageDB_admin_requests )- for 6 > > days I have status of this request "Approved", but I can't do fedpkg > > clone... What is wrong? What next step I should do? > > You don't mention the package here, but I suspect it was 'mozjs38' ? > > It looks like it was processed right after you requested it, but > something went wrong and it wasn't added. ;( > > We are looking into why that happened, but in the mean time I have > reprocessed it and it's there now: > > https://admin.fedoraproject.org/pkgdb/package/mozjs38/ Yes, it is mozjs38. Thanks, M. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 23 Release Readiness Meeting on Thursday, October 22nd, 6PM (UTC)
This Thursday, we will meet on irc.freenode.net in #fedora-meeting-2 to make sure we are coordinated and ready for the release of Fedora 23 on Tuesday, October 27, 2015. Please note that this meeting will occur even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. The meeting is scheduled at 6PM (UTC). Please follow the [FedoCal] link to find the time of the meeting in your time-zone. [FedoCal] https://apps.fedoraproject.org/calendar/meeting/3103/ You may received this message several times as this meeting is opened to all teams. I also hope this will raise awareness and more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. Thanks for attending, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[POC-change] Fedora packages point of contact updates
Change in package status over the last 168 hours 8 packages were orphaned bouncycastle-pkix [epel7] was orphaned by gil Bouncy Castle PKIX, CMS, EAC, TSP, PKCS, OCSP, CMP, and CRMF APIs https://admin.fedoraproject.org/pkgdb/package/bouncycastle-pkix ctapi-common [master] was orphaned by tmraz Common files and packaging infrastructure for CT-API modules https://admin.fedoraproject.org/pkgdb/package/ctapi-common lonote [f22, f21, master] was orphaned by cheeselee Personal Notebook on browser https://admin.fedoraproject.org/pkgdb/package/lonote openct [master] was orphaned by tmraz Middleware framework for smart card terminals https://admin.fedoraproject.org/pkgdb/package/openct php-ZendFramework [el5] was orphaned by noodles Leading open-source PHP framework https://admin.fedoraproject.org/pkgdb/package/php-ZendFramework rubygem-ghost [f23, f22, f21, master] was orphaned by madsa Allows you to create, list, and modify local hostnames https://admin.fedoraproject.org/pkgdb/package/rubygem-ghost shutter [el6, epel7] was orphaned by cheeselee GTK+2-based screenshot application written in Perl https://admin.fedoraproject.org/pkgdb/package/shutter thinkfan [f23, f22, f21, master] was orphaned by madsa A simple fan control program https://admin.fedoraproject.org/pkgdb/package/thinkfan 24 packages were retired - CableSwig [f23, master] was retired by till Create interfaces to interpreted languages for templated code https://admin.fedoraproject.org/pkgdb/package/CableSwig apache-scout [f23, master] was retired by till JSR 93 (JAXR) implementation https://admin.fedoraproject.org/pkgdb/package/apache-scout apacheds-ldap-client [master] was retired by gil ApacheDS LDAP Client API https://admin.fedoraproject.org/pkgdb/package/apacheds-ldap-client apacheds-shared [master] was retired by gil Shared APIs of Apache Directory Project https://admin.fedoraproject.org/pkgdb/package/apacheds-shared covered [el5] was retired by till Verilog code coverage analyzer https://admin.fedoraproject.org/pkgdb/package/covered hbase [f23, master] was retired by till A database for Apache Hadoop https://admin.fedoraproject.org/pkgdb/package/hbase libhtp [el6] was retired by bochecha Security-aware parser for the HTTP protocol and the related bits and pieces https://admin.fedoraproject.org/pkgdb/package/libhtp lonote [f23] was retired by cheeselee Personal Notebook on browser https://admin.fedoraproject.org/pkgdb/package/lonote mate-applet-lockkeys [f23, master] was retired by till MATE Keyboard LED indicator https://admin.fedoraproject.org/pkgdb/package/mate-applet-lockkeys mate-themes-extras [f23, master] was retired by till Extra gtk-2/3 themes for gtk based desktops https://admin.fedoraproject.org/pkgdb/package/mate-themes-extras maven-skins [master] was retired by akurtakov Maven Skins https://admin.fedoraproject.org/pkgdb/package/maven-skins netbeans-platform [f23, master] was retired by till NetBeans Platform https://admin.fedoraproject.org/pkgdb/package/netbeans-platform nodejs-grunt-contrib-copy [f23, master] was retired by till Copy files and folders https://admin.fedoraproject.org/pkgdb/package/nodejs-grunt-contrib-copy oat [f23, master] was retired by till Attestation Service & Host Agent based on OpenAttestation SDK https://admin.fedoraproject.org/pkgdb/package/oat oozie [f23, master] was retired by till A work-flow scheduling system for Apache Hadoop https://admin.fedoraproject.org/pkgdb/package/oozie pig [f23, master] was retired by till Apache Pig https://admin.fedoraproject.org/pkgdb/package/pig pure [f23, master] was retired by till A term-rewriting functional programming language https://admin.fedoraproject.org/pkgdb/package/pure pure-glpk [f23, master] was retired by till GLPK interface for the Pure programming language https://admin.fedoraproject.org/pkgdb/package/pure-glpk pyjigdo [f23, master] was retired by till Python version of Jigdo, slightly modified https://admin.fedoraproject.org/pkgdb/package/pyjigdo python-rfc6266 [f23, master] was retired by till Parse and generate Content-Disposition headers https://admin.fedoraproject.org/pkgdb/package/python-rfc6266 python-ufc [f23, master] was retired by till A unified framework for finite element assembly https://admin.fedoraproject.org/pkgdb/package/python-ufc rubygem-celluloid [f23, master] was retired by till Actor-based concurrent object framework for Ruby https://admin.fedoraproject.org/pkgdb/package/rubygem-celluloid spark [f23, master] was retired by till Lightning-fast cluster computing https://admin.fedoraproject.org/pkgdb/package/spark vfrnav [f23, master] was
Re: Recommended way of proposing changes in someone else Fedora packages configuration
On Sun, 18 Oct 2015 21:12:42 -0400 Neal Gompa wrote: > Perhaps GitLab might be more appealing, since it is a FOSS service > and it could be brought in-house relatively easily? Not really. There was an effort started I think in 2012 or 2013 to package it... https://fedoraproject.org/wiki/GitLab I don't think adapting it would be at all easy. kevin pgpNL8MoLznS9.pgp Description: OpenPGP digital 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: New package request
On Mon, 19 Oct 2015 12:53:39 +0200 Marek Skalický wrote: > Hello everyone, > does someone know how the "Request new package" in pkgdb works? > (https://fedoraproject.org/wiki/PackageDB_admin_requests )- for 6 > days I have status of this request "Approved", but I can't do fedpkg > clone... What is wrong? What next step I should do? You don't mention the package here, but I suspect it was 'mozjs38' ? It looks like it was processed right after you requested it, but something went wrong and it wasn't added. ;( We are looking into why that happened, but in the mean time I have reprocessed it and it's there now: https://admin.fedoraproject.org/pkgdb/package/mozjs38/ kevin pgp_mW9Wtekl4.pgp Description: OpenPGP digital 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
Fedora 23 Go/No-Go Meeting on Thursday, October 22nd, 4PM (UTC)
Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 23. The meeting is scheduled at 4PM (UTC). Please follow the [FedoCal] link to find the time of the meeting in your time-zone. [FedoCal] https://apps.fedoraproject.org/calendar/meeting/3105/ "Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 23 Final Blocker list: https://qa.fedoraproject.org/blockerbugs/milestone/23/final/buglist Thanks for attending, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: Ownership of /usr/lib/rpm/fileattrs
On 2015-10-19, Petr Pisar wrote:
> One can perceive the package packages as rpm-build plugins. Having the
> dependency on rpm-build does not look wrong in the end.
>
One must perceive the scripts as rpm-build plugins because they are
installed into rpm-build's package directory. Otherwise the were
installed into /usr/bin (or /usr/libexec). So the dependency on
rpm-build is correct.
If the scripts are usable without rpmbuild, then the *.{prov,req}
scripts should go into different binary package then the *.attr files.
The package with *.attr files will require both rpm-build and the
package with *.{prov,req} scripts.
-- Petr
--
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: Recommended way of proposing changes in someone else Fedora packages configuration
On 2015-10-19, Kevin Kofler wrote: > 1. git clone … > 2. commit your changes > 3. git format-patch > 4. attach to Bugzilla > The 3rd and 4th step can be simplified to "git send-bugzilla" command. Although I think it can attach a patch only to already existing bug report. This could be implemented and fedpkg tool could gain the capability to send patches from local dist-git branch :) -- Petr -- 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: Ownership of /usr/lib/rpm/fileattrs
On 2015-10-16, Orion Poplawski wrote: > only rpm-mpi-hooks requires rpm-build for directory ownership, while > javapackages-tools takes the route of owning the directory. However, I'd > rather rpm-mpi-hooks not require rpm-build as it's not really necessary other > than for this directory. The simple thing I think would be for rpm to own the > directory. Does that seem reasonable? > If you move the directory from rpm-build to rpm, then all the packages should require rpm instead of rpm-build. But that contradicts your wish "I'd rather rpm-mpi-hooks not require rpm-build as it's not really necessary other than for this directory". rpm-mpi-hooks does not need rpm more or less than it needs rpm-build, does it? If the only reason for the dependency is the ownership, then co-owning the directory as javapackages-tools does is the right way. But the directory hosts dependency generators executed by rpmbuild. Not by rpm. Moving the ownership from rpm-build to rpm sounds semantically wrong. One can perceive the package packages as rpm-build plugins. Having the dependency on rpm-build does not look wrong in the end. -- Petr -- 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: Unresponsive maintainer and unupdated package
On 19/10/15 12:33, Chaoyi Zha wrote: Ah, there is a Node.js list? I'll look into it and see if anything is going on over there. There is, yes: https://lists.fedoraproject.org/mailman/listinfo/nodejs Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-23 Branched report: 20151019 changes
Compose started at Mon Oct 19 07:15:03 UTC 2015 Broken deps for armhfp -- [openstack-swift] openstack-swift-2.3.0-2.fc23.noarch requires python-pyeclib Broken deps for i386 -- [openstack-swift] openstack-swift-2.3.0-2.fc23.noarch requires python-pyeclib Broken deps for x86_64 -- [openstack-swift] openstack-swift-2.3.0-2.fc23.noarch requires python-pyeclib Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Size of added packages: 0 (0 ) Size change of modified packages: 0 (0 ) Size of removed packages: 0 (0 ) Size change: 0 (0 ) Compose finished at Mon Oct 19 11:52:29 UTC 2015 -- 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: Unresponsive maintainer and unupdated package
Hi Chaoyi, On Mon, Oct 19, 2015 at 5:08 PM, Chaoyi Zha wrote: > Node.js v0.12 has since become outdated. The page about updating it to 0.12 > for F23 is likely outdated as well by now. We may want to create a new page > if it is needed. > > Here is the latest "LTS" release: > https://nodejs.org/en/blog/release/v4.2.1/ > > Have you checked any existing nodejs module packages if they compile/build/run fine against this 4.2.1 version? Maybe try creating Copr repo and rebuilding all the existing nodejs packages against it. Regards, Parag. -- 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: Unresponsive maintainer and unupdated package
Node.js v0.12 has since become outdated. The page about updating it to 0.12 for F23 is likely outdated as well by now. We may want to create a new page if it is needed. Here is the latest "LTS" release: https://nodejs.org/en/blog/release/v4.2.1/ On Mon, Oct 19, 2015, 7:32 AM Chaoyi Zha wrote: > Ah, there is a Node.js list? I'll look into it and see if anything is > going on over there. > > On Mon, Oct 19, 2015, 7:32 AM Tom Hughes wrote: > >> On 19/10/15 12:22, Chaoyi Zha wrote: >> >> > I think someone else has also recently e-mailed about this unresponsive >> > maintainer, "patches". >> > >> > I am looking to update one of his packages, "nodejs" >> > >> > It is currently at version 0.10 in our PkgDB but the current version is >> > 4.2.1 >> > >> > I would be happy to update and maintain this package, but I do not have >> > any rights to it and it is not orphaned yet. >> >> Updating nodejs is nothing to be done lightly. It was supposed to be >> updated to 0.12 for F23: >> >>https://fedoraproject.org/wiki/Changes/NodeJS012 >> >> There was also an io.js plan: >> >>https://fedoraproject.org/wiki/Changes/iojs >> >> I don't think that either happened in the end though, and obviously >> events have been somewhat overtaken by the remerger with io.js. >> >> I'd suggest contacting the nodejs list in the first instance anyway as >> that is where all the experts will be, including patches normally. >> >> Tom >> >> -- >> Tom Hughes (t...@compton.nu) >> http://compton.nu/ >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > -- 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: Unresponsive maintainer and unupdated package
Ah, there is a Node.js list? I'll look into it and see if anything is going on over there. On Mon, Oct 19, 2015, 7:32 AM Tom Hughes wrote: > On 19/10/15 12:22, Chaoyi Zha wrote: > > > I think someone else has also recently e-mailed about this unresponsive > > maintainer, "patches". > > > > I am looking to update one of his packages, "nodejs" > > > > It is currently at version 0.10 in our PkgDB but the current version is > > 4.2.1 > > > > I would be happy to update and maintain this package, but I do not have > > any rights to it and it is not orphaned yet. > > Updating nodejs is nothing to be done lightly. It was supposed to be > updated to 0.12 for F23: > >https://fedoraproject.org/wiki/Changes/NodeJS012 > > There was also an io.js plan: > >https://fedoraproject.org/wiki/Changes/iojs > > I don't think that either happened in the end though, and obviously > events have been somewhat overtaken by the remerger with io.js. > > I'd suggest contacting the nodejs list in the first instance anyway as > that is where all the experts will be, including patches normally. > > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Unresponsive maintainer and unupdated package
On 19/10/15 12:22, Chaoyi Zha wrote: I think someone else has also recently e-mailed about this unresponsive maintainer, "patches". I am looking to update one of his packages, "nodejs" It is currently at version 0.10 in our PkgDB but the current version is 4.2.1 I would be happy to update and maintain this package, but I do not have any rights to it and it is not orphaned yet. Updating nodejs is nothing to be done lightly. It was supposed to be updated to 0.12 for F23: https://fedoraproject.org/wiki/Changes/NodeJS012 There was also an io.js plan: https://fedoraproject.org/wiki/Changes/iojs I don't think that either happened in the end though, and obviously events have been somewhat overtaken by the remerger with io.js. I'd suggest contacting the nodejs list in the first instance anyway as that is where all the experts will be, including patches normally. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- 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: Unresponsive maintainer and unupdated package
You have to go through this process: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers I just filed a ticket to FESCo: https://fedorahosted.org/fesco/ticket/1492 - Original Message - > From: "Chaoyi Zha" > To: "Development discussions related to Fedora" > > Sent: Monday, October 19, 2015 1:22:09 PM > Subject: Unresponsive maintainer and unupdated package > > > > Hi, > > I think someone else has also recently e-mailed about this unresponsive > maintainer, "patches". > > I am looking to update one of his packages, "nodejs" > > It is currently at version 0.10 in our PkgDB but the current version is 4.2.1 > > I would be happy to update and maintain this package, but I do not have any > rights to it and it is not orphaned yet. > > How should I go about updating this package? > > Thanks, > Chaoyi > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unresponsive maintainer and unupdated package
Hi, I think someone else has also recently e-mailed about this unresponsive maintainer, "patches". I am looking to update one of his packages, "nodejs" It is currently at version 0.10 in our PkgDB but the current version is 4.2.1 I would be happy to update and maintain this package, but I do not have any rights to it and it is not orphaned yet. How should I go about updating this package? Thanks, Chaoyi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20151019 changes
Compose started at Mon Oct 19 05:15:03 UTC 2015 Broken deps for i386 -- [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [alliance] alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2 [ambari] ambari-server-1.5.1-5.fc23.noarch requires mvn(org.apache.directory.shared:shared-ldap) [eclipse-jbosstools] eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires osgi(org.eclipse.tm.terminal) [fawkes] fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so [gnash] 1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 [golang-github-kraman-libcontainer] golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch requires golang(github.com/docker/docker/pkg/netlink) [golang-github-prometheus-prometheus] golang-github-prometheus-prometheus-devel-0.15.0-1.fc24.noarch requires golang(gopkg.in/fsnotify.v1) [js-of-ocaml] js-of-ocaml-2.4-8.fc23.i686 requires ocaml(runtime) = 0:4.02.2 js-of-ocaml-2.4-8.fc23.i686 requires ocaml(Lwt_list) = 0:0ce891783d3177cd33ebd9ed60d4b62d js-of-ocaml-2.4-8.fc23.i686 requires ocaml(Lwt) = 0:6f62eda62952a3e464e9c34a825cf0de [nodejs-mongodb] nodejs-mongodb-2.0.43-1.fc24.noarch requires npm(es6-promise) >= 0:2.1.1 [openstack-heat-gbp] openstack-heat-gbp-2015.1.1-1.fc24.noarch requires openstack-heat-engine < 0:2015.2 [openstack-neutron] 1:python-neutron-7.0.0-0.5.0rc2.fc24.noarch requires python-oslo-versionedobjects >= 0:0.9.0 [openstack-neutron-gbp] openstack-neutron-gbp-2015.1.1-1.fc24.noarch requires openstack-neutron < 0:2015.2 [openstack-nova] 1:python-nova-12.0.0-1.fc24.noarch requires python-oslo-versionedobjects >= 0:0.9.0 [pion-net] pion-net-5.0.7-1.fc24.i686 requires libboost_thread.so.1.58.0 pion-net-5.0.7-1.fc24.i686 requires libboost_system.
Unresponsive maintainer: patches
Hi, As per the Policy for nonresponsive package maintainers: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers I am writing here to ask you, if any of you know how to get in contact with T.C. Hollingsworth? It appears he has been inactive for +6 months and I to contact him about some of his packages. Thank you, Viktor -- 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: New package request
Dne 19.10.2015 v 12:53 Marek Skalický napsal(a): > Hello everyone, > does someone know how the "Request new package" in pkgdb works? > (https://fedoraproject.org/wiki/PackageDB_admin_requests )- for 6 days I > have status of this request "Approved", but I can't do fedpkg clone... > What is wrong? What next step I should do? Usually this happened when you have different email in bugzilla and in FAS. Not sure if this can be the reason with new pkgdb thou. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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: Variable expansion in COPR external URL?
Dne 17.10.2015 v 23:55 Dave Johansen napsal(a):
> How can I do a variable expansion that doesn't have - before and after? I
> tried "slc${releasever}X" [1] and
> "slc$releaseverX" [2] but neither worked.
> Thanks,
> Dave
>
> [1]:
> https://copr-be.cloud.fedoraproject.org/results/daveisfera/odb_2.3_cern/epel-5-i386/00128584-odb/root.log.gz
> [2]:
> https://copr-be.cloud.fedoraproject.org/results/daveisfera/odb_2.3_cern/epel-5-i386/00128585-odb/root.log.gz
>
>
There is nothing special in Copr about this. Copr (or mock to be precise) just
pass --releasever to dnf/yum.
Looking at dnf code - and I assume yum will have similar code... There is in
dnf/conf/parser.py the regular expression:
_KEYCRE = re.compile(r"\$(\w+)")
which eat everything until first non word character.
If you want smarter substitution, then please file RFE against DNF. Or even
better send patch. :)
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New package request
Hello everyone, does someone know how the "Request new package" in pkgdb works? (https://fedoraproject.org/wiki/PackageDB_admin_requests )- for 6 days I have status of this request "Approved", but I can't do fedpkg clone... What is wrong? What next step I should do? Thanks, Marek -- 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: ansible in Fedora 23+ (python3)
On 10/19/2015 11:37 AM, Fabio Alessandro Locati wrote: > 2015-10-19 2:33 GMT+02:00 Kevin Kofler : >> Dusty Mabe wrote: >>> Does anyone have a good solution for this? Obviously it would be nice >>> if ansible went to python3 but I think they have stated clearly that >>> they are sticking with python2 for backwards compat with systems that >>> still need 2.4. >> >> I don't understand why still nobody has forked Ansible to get it out of the >> stone age. > > It's not so easy. Ansible is based on Twisted which is not yet 100% > Python3 compatible, as far as I understood. Does the code which is injected into managed machines use Twisted? That would be a bit odd. I think there are two different levels of Python 3 support, one for the managing host (desirable but not essential), and one for the managed hosts (increasingly important if there are systems which only have Python 3 and cannot install Python 2). Florian -- 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: ansible in Fedora 23+ (python3)
2015-10-19 2:33 GMT+02:00 Kevin Kofler : > Dusty Mabe wrote: >> Does anyone have a good solution for this? Obviously it would be nice >> if ansible went to python3 but I think they have stated clearly that >> they are sticking with python2 for backwards compat with systems that >> still need 2.4. > > I don't understand why still nobody has forked Ansible to get it out of the > stone age. It's not so easy. Ansible is based on Twisted which is not yet 100% Python3 compatible, as far as I understood. Also, the problem is that RedHat still supports RHEL5 systems which for today standards are totally legacy and therefore it has to run on Python 2.4. -- Fabio Alessandro Locati PGP Fingerprint: B960 BE9D E7A8 FA12 273A 98BB 6D6A 29D6 709A 7851 https://keybase.io/fale -- 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: ansible in Fedora 23+ (python3)
On Mon, 19 Oct 2015, at 01:33, Kevin Kofler wrote: > Dusty Mabe wrote: > > Does anyone have a good solution for this? Obviously it would be nice > > if ansible went to python3 but I think they have stated clearly that > > they are sticking with python2 for backwards compat with systems that > > still need 2.4. > > I don't understand why still nobody has forked Ansible to get it out of > the > stone age. > > Kevin Kofler > A solution where everybody wins could be shifting the requirement from 2.4 to 2.7 as of a given release point. Older machines (I believe RHEL 5.something is the oldest target) can have Python 2.7 installed, and nobody should be building out new servers with RHEL 5 on them anymore. Possibly a discussion the Ansible mailing list have had many many times before though, maybe we'll see a different attitude under Red Hat's leadership. --- Richard Bradfield -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
