Re: EPEL Status of openstack-nova
16.4.2014 23.20, Matthias Runge kirjoitti: On Sat, Apr 12, 2014 at 10:33:50AM +0300, Anssi Johansson wrote: I'm still of the opinion that if a package in EPEL is no longer maintained and it has known security issues, it should be removed from EPEL. That will happen, in the next few weeks, as far as I know. Matthias Are we there yet? # yum search openstack-nova .. openstack-nova : OpenStack Compute (nova) openstack-nova-api : OpenStack Nova API services openstack-nova-cert : OpenStack Nova certificate management service openstack-nova-common : Components common to all OpenStack Nova services openstack-nova-compute : OpenStack Nova Virtual Machine control service openstack-nova-console : OpenStack Nova console access services openstack-nova-doc : Documentation for OpenStack Compute openstack-nova-network : OpenStack Nova Network control service openstack-nova-novncproxy : Proxy server for noVNC traffic over Websockets openstack-nova-objectstore : OpenStack Nova simple object store service openstack-nova-scheduler : OpenStack Nova VM distribution service openstack-nova-volume : OpenStack Nova storage volume control service ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[Base] CANCELED: Base Design WG agenda meeting 04 July 2014 15:00 UTC on #fedora-meeting
Due to the holiday in the US and no real agenda for today i'm canceling the meeting for today. Continued next week. Thanks everyone! Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- 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: kde-4.13.x update for f20
On Ter, 2014-07-01 at 12:17 -0500, Rex Dieter wrote: KDE SIG has been discussing moving forward with another kde x.y+1 update for Fedora 20, largely due to it's extended lifetime (and f21's delayed release), extending the same rationale per http://fedoraproject.org/wiki/SIGs/KDE/Update_policy There have been kde-4.13.1 packages available for testing and feedback in a 3rd-party kde-unstable repo (see http://fedoraproject.org/wiki/SIGs/KDE/Testing ) for quite some time. We're currently tracking all kde-4.13 blocker-worthy issues in bugzilla, https://bugzilla.redhat.com/show_bug.cgi?id=kde-4.13 Hi, yesterday I saw I have 10 000 messages to read on this ML :) , but this one brought me attention , are you suggesting try update to kde-redhat.org ? http://apt.kde-redhat.org/apt/kde-redhat/fedora/kde.repo have 3 repos is to use kde stable ? this will equal to future Fedora 20 , with kde 13 , many years ago I try use kde-redhat and I saw that a quite different filosofy that was in Fedora The most significant change involved will be moving to a new desktop search architecture, called baloo, which addresses a long-time pain-point and has been generally well-received. Any comments or concerns? I go for it Many thanks, -- Sérgio M. B. -- 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: kde-4.13.x update for f20
Am 04.07.2014 12:02, schrieb Sérgio Basto: http://apt.kde-redhat.org/apt/kde-redhat/fedora/kde.repo have 3 repos is to use kde stable ? this will equal to future Fedora 20 , with kde 13 , many years ago I try use kde-redhat and I saw that a quite different filosofy that was in Fedora in the meantime Rex Dieter became the core maintainer of the Fedora packages too - kde-redhat is the playground for Fedora packaging and kde-unstable is the preview of the next major update kde-unstable is not always recommended and should be taken with care, in case of 4.13 it is quite stable kde-testing usually has the same packaging as updates-testing 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
Re: free seats in Env and Stacks WG - volunteers wanted
On 07/02/2014 11:10 AM, Marcela Mašláňová wrote: On 07/01/2014 11:31 AM, Marcela Maslanova wrote: Env and Stacks Working Group has noble plan to make development in Fedora easier and also work with new technologies, which are not in Fedora yet. The whole statement can be found here: https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document There is missing Atomic and/or Docker, because all members were mostly interested in things mentioned in the document than looking at containers. I believe we need someone who can pick what will be in Fedora base image. Details can be found in Matt statement: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-June/000431.html We don't have manpower to work on all projects, but we started to work or co-operate on these: 1/ testing additional repositories – Playground repo https://fedoraproject.org/wiki/Changes/Playground_repository Playground plugin is similar to Copr plugin http://dnf.baseurl.org/2014/03/19/copr-plugin/ 2/ automation – Automated packages review tools https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/Automated_packages_review_tools 3/ automation – Taskotron tool for Fedora tests https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan 4/ Build Systems – Copr http://copr.fedoraproject.org/ 5/ Software Collections in Fedora https://fedoraproject.org/wiki/Changes/SCL 6/ DevAssistant http://devassistant.org/ 7/ Continuous Integration - prototype of few projects If you are interested in current topics or containers, then please let us know on env-and-sta...@lists.fedoraproject.org what you want to do and what you did until now. I received some private replies, but I'd like to give opportunity to wider audience. Thanks, Marcela Deadline for submission is Sunday, 6th July. Marcela Hello Marcela, I would like to be a volunteer in Env and Stacks WG seet. I have been working with DevAssistant a bit. I am the owner of DevAssistant GUI. Currently I am working on rebase-helper project. The project should be add to upstream monitoring tool soon (https://github.com/phracek/rebase-helper) https://admin.fedoraproject.org/pkgdb/package/rebase-helper/ I am also the owner of preupgrade-assistant package but it is releated to RHEL especially. Greetings Petr -- Best regards / S pozdravem Petr Hracek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
FESCo candidature announcement
Hi all. I would like to announce my candidature for FESCo member. Besides goals I'm interested [1] in I would like to stress, that I'm prepared to fight for changes, that would be beneficial for Fedora users and developers. I don't want to make decisions on any topic without prior research and proper understanding. I think all important changes should be thoroughly discussed and not made silently. Have you any questions, feel free to ping me on IRC (#fedora-devel) or drop an email. Tomas [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations#Candidates -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.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
Re: defining firewalld services
On 07/03/2014 09:32 PM, Stef Walter wrote:
On 03.07.2014 15:39, Rex Dieter wrote:
I'm looking into providing a predefined firewalld service definition for
kde-connect, per
https://bugzilla.redhat.com/show_bug.cgi?id=1115547
Looks like it's as easy as dropping an xml snippet into
/usr/lib/firewalld/services/
I'm also noticing currently that the only package besides fallwalld itself
doing this is cockpit, which includes a %post scriptlet:
# firewalld only partially picks up changes to its services files
# without this
test -f %{_bindir}/firewall-cmd firewall-cmd --reload --quiet || true
Is this the recommended approach? If so, I'll follow this lead, and maybe
start work on drafting some packaging guidelines.
Thomas Woerner would be the one to work out those guidelines.
Yes.
But to explain ... apparently there are two firewalld environments.
When you install a service file it only affects the installed
environment (used after a reboot) and not the current runtime environment.
This means that a user can't immediately use your service definition in
a command like:
$ firewall-cmd --add-service=cockpit
The command:
$ firewall-cmd --reload
... makes newly installed service files available in the runtime
environment. I guess this is sorta analogous to 'systemctl daemon-reload'.
Newly added services and zones are available in the permanent
environment of firewalld, where they can be used with the UI and command
line tools.
To have a newly added service or zone in the runtime environment it is
needed to reload firewalld: firewall-cmd --reload or systemctl reload
firewalld.service.
Stef
Thomas
--
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: Introducing Python 3.5 nightly builds for Fedora
Dne 4.7.2014 02:06, Zbigniew Jędrzejewski-Szmek napsal(a): Hi, looks like something I might use for development of Python software. But for this to be truly useful, I'd need a bunch of stuff on top, at least numpy/scipy, but also pytables, matplotlib. Without that it would be even hard to test building of packages, since they often depend on those modules (and others of course). Is there any chance you could add cascaded builds of the most popular extensions? Hi Zbyszek, Thanks for your feedback. Unfortunately we do not plan to build most popular extensions in this repository. We would have to select those and that would lead to either 1) unhappy people (without necessary packages) or 2) rebuilding almost the whole Python stack in Copr as SCL (not enough man power, not worth the work). You can either use pip to install dependencies or build your dependencies as RPMs in your own Copr/mock. Feel free to ping me on IRC if you need help. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Rebase-helper in Fedora 20
Hi, a small summary about Rebase-helper project. The purposeoftherebase-helper is to save developer'stime during package rebases. Rebase-helper is intended to be run in the cloned (Fedora) package repo and needs only the path to the archive (tarball) withnew upstream sources. The rest is automated. If any decision is needed, the developer is prompted. The current workflow is as follows: * Downloadarchive with the current (old)and new sources * For all existing patches applythem, one at a time, to new sourcesand help with rebasing patches if needed (using tool like 'meld') * Build packages (old and new) automatically. * In the future we will perform various checks (rpmdiff, API/ABI check, etc.) and add them to Upstream Monitoring in Fedora GitHub repository is: https://github.com/phracek/rebase-helper If you would like to try rebase-helper then only clone the github repository or install rebase-helper package which is already available in Fedora 20. And try: *rebase-helper upstream-sources*** If you discover any issues,feel free to add anewissue ongithub https://github.com/phracek/rebase-helper/issues?state=open and we will work on fixingthem based on their severity. What will be another steps? * Add support for rpmdiff * Add support for API/ABI check * Add support formore patching mechanisms - like git patch alghorithm (mentioned by Kamil Dudka) * Upstream Monitoring in Fedora * you name it... ;) Any feedbackandcomments are welcome either on IRC: #rebase-helper or to us. Contact persons (alphabetically): - Jiri Popelka (jpopelka) - Tomas Hozza (thozza) - Petr Hracek (phracek) Rebase-helper team Greetings Petr -- Best regards / S pozdravem Petr Hracek -- 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: Rebase-helper in Fedora 20
On Jul 4, 2014 4:39 PM, Petr Hracek phra...@redhat.com wrote: Hi, Hi, a small summary about Rebase-helper project. The purpose of the rebase-helper is to save developer's time during package rebases. Rebase-helper is intended to be run in the cloned (Fedora) package repo and needs only the path to the archive (tarball) with new upstream sources. The rest is automated. If any decision is needed, the developer is prompted. The current workflow is as follows: Download archive with the current (old) and new sources For all existing patches apply them, one at a time, to new sources and help with rebasing patches if needed (using tool like 'meld') Build packages (old and new) automatically. In the future we will perform various checks (rpmdiff, API/ABI check, etc.) and add them to Upstream Monitoring in Fedora Cool project! GitHub repository is: https://github.com/phracek/rebase-helper If you would like to try rebase-helper then only clone the github repository or install rebase-helper package which is already available in Fedora 20. And try: rebase-helper upstream-sources I will test it tonight. If you discover any issues, feel free to add a new issue on github https://github.com/phracek/rebase-helper/issues?state=open Sure! and we will work on fixing them based on their severity. What will be another steps? Add support for rpmdiff Add support for API/ABI check Add support for more patching mechanisms - like git patch alghorithm (mentioned by Kamil Dudka) Upstream Monitoring in Fedora you name it... ;) Any feedback and comments are welcome either on IRC: #rebase-helper or to us. Contact persons (alphabetically): - Jiri Popelka (jpopelka) - Tomas Hozza (thozza) - Petr Hracek (phracek) Rebase-helper team Greetings Petr -- Best regards / S pozdravem Petr Hracek -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Odd debugedit message: -b arg has to be either the same length as -d arg, or more than 1 char longer
I'm seeing this message: extracting debug info from /home/dhowells/rpmbuild/BUILDROOT/cross-gcc-4.9.0-2.fc21.x86_64/usr/lib/gcc/hppa-linux-gnu/4.9.0/libcloog-isl.so.4 /usr/lib/rpm/debugedit: -b arg has to be either the same length as -d arg, or more than 1 char longer but only on some machines. Anyone know what it portends? rpm -qf /usr/lib/rpm/debugedit rpm-build-4.11.2-2.fc20.x86_64 on both machines I've tried it on. David -- 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: Odd debugedit message: -b arg has to be either the same length as -d arg, or more than 1 char longer
On Fri, 04 Jul 2014 17:01:00 +0100 David Howells dhowe...@redhat.com wrote: I'm seeing this message: extracting debug info from /home/dhowells/rpmbuild/BUILDROOT/cross-gcc-4.9.0-2.fc21.x86_64/usr/lib/gcc/hppa-linux-gnu/4.9.0/libcloog-isl.so.4 /usr/lib/rpm/debugedit: -b arg has to be either the same length as -d arg, or more than 1 char longer but only on some machines. Anyone know what it portends? rpm -qf /usr/lib/rpm/debugedit rpm-build-4.11.2-2.fc20.x86_64 on both machines I've tried it on. as a user or root? IIRC building as root leads to strange errors sometimes Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Announce] Simple Patch Policy
Dear all, Following the approval of the Simple Patch policy, all the necessary pieces are now in place. * The policy can be read at https://fedoraproject.org/wiki/Policy_for_simple_patches * The bug tracking simple patch requests is https://bugzilla.redhat.com/show_bug.cgi?id=SIMPLE_PATCHES * A script automating most of the process of validating and processing the request can be found at https://github.com/manisandro/fedora-process-simple-patch/blob/master/process-simple-patch.py Proven packagers interested in helping out should add themselves to the SIMPLE_PATCHES bug. Any fixes, suggestions and improvements to the process-simple-patch.py are very welcome! Thanks, Sandro ___ 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: Koschei - continuous rebuilds for packages
On Thu, 03 Jul 2014 17:20:58 +0200 jpac...@redhat.com jpac...@redhat.com wrote: Hi Michael, Detecting soname bumps and doing real rebuilds instead of scratch build should be possible. Koschei could automatically start rebuilding dependent packages AFTER you update the library in rawhide. That's the goal. Note that in order to do this it would need to have provenpackager powers to commit to pkgs git and koji certs to do builds. Not impossible, but we would probibly want it running inside Fedora Infrastructure and need to be careful security wise. But if you want to know what will break before you do the update then it will be more complicated, because Koschei will need to manage separate Koji tags and obviously first get permission to do so and I'm not sure whether relengs would be willing to make this happen. That would be convenient - at least for critical-path packages. Anyway, lets ask lkocman (CC) about Koji tags. To deal with tags it would likely need a koji admin cert, which we would want to be very sure it didn't do anything bad. kevin 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: Odd debugedit message: -b arg has to be either the same length as -d arg, or more than 1 char longer
Dan Horák d...@danny.cz wrote: as a user or root? IIRC building as root leads to strange errors sometimes As a user in both cases. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21FTBFS patches awaiting review
The following F21FTBFS patches have been waiting for review for at least a week: ax25-tools: https://bugzilla.redhat.com/show_bug.cgi?id=1105990 banshee-community-extensions: https://bugzilla.redhat.com/show_bug.cgi?id=1105994 buildbot: https://bugzilla.redhat.com/show_bug.cgi?id=1106019 byzanz: https://bugzilla.redhat.com/show_bug.cgi?id=1106024 cadaver:https://bugzilla.redhat.com/show_bug.cgi?id=1106029 cl-asdf:https://bugzilla.redhat.com/show_bug.cgi?id=1106048 compat-gcc-296: https://bugzilla.redhat.com/show_bug.cgi?id=1106075 compat-gcc-34: https://bugzilla.redhat.com/show_bug.cgi?id=1106077 cssed: https://bugzilla.redhat.com/show_bug.cgi?id=1037027 cvs2cl: https://bugzilla.redhat.com/show_bug.cgi?id=1106110 d52:https://bugzilla.redhat.com/show_bug.cgi?id=1106116 drwright: https://bugzilla.redhat.com/show_bug.cgi?id=1106182 f2c:https://bugzilla.redhat.com/show_bug.cgi?id=1037057 ggobi: https://bugzilla.redhat.com/show_bug.cgi?id=1037083 ggz-gtk-client: https://bugzilla.redhat.com/show_bug.cgi?id=1037084 gimp-fourier-plugin: https://bugzilla.redhat.com/show_bug.cgi?id=1106621 gnome-pie: https://bugzilla.redhat.com/show_bug.cgi?id=1106682 gocl: https://bugzilla.redhat.com/show_bug.cgi?id=1037097 gtk-v4l:https://bugzilla.redhat.com/show_bug.cgi?id=1037113 idjc: https://bugzilla.redhat.com/show_bug.cgi?id=1106795 ivtv-utils: https://bugzilla.redhat.com/show_bug.cgi?id=1037142 kdegames3: https://bugzilla.redhat.com/show_bug.cgi?id=1106999 kpilot: https://bugzilla.redhat.com/show_bug.cgi?id=1107056 kpolynome: https://bugzilla.redhat.com/show_bug.cgi?id=1107057 ktechlab: https://bugzilla.redhat.com/show_bug.cgi?id=1107080 libmash:https://bugzilla.redhat.com/show_bug.cgi?id=1106038 lxdm: https://bugzilla.redhat.com/show_bug.cgi?id=1037184 lxpanel:https://bugzilla.redhat.com/show_bug.cgi?id=1037185 lxpolkit: https://bugzilla.redhat.com/show_bug.cgi?id=1037186 magic: https://bugzilla.redhat.com/show_bug.cgi?id=1037190 monodevelop-vala: https://bugzilla.redhat.com/show_bug.cgi?id=1106235 msp430-libc:https://bugzilla.redhat.com/show_bug.cgi?id=1106247 mstflint: https://bugzilla.redhat.com/show_bug.cgi?id=1037207 nautilus-actions: https://bugzilla.redhat.com/show_bug.cgi?id=1106267 ngspice:https://bugzilla.redhat.com/show_bug.cgi?id=1106295 phasex: https://bugzilla.redhat.com/show_bug.cgi?id=1037245 phodav: https://bugzilla.redhat.com/show_bug.cgi?id=1106318 piccolo2d: https://bugzilla.redhat.com/show_bug.cgi?id=1106627 posterazor: https://bugzilla.redhat.com/show_bug.cgi?id=1037255 premake:https://bugzilla.redhat.com/show_bug.cgi?id=1106672 q: https://bugzilla.redhat.com/show_bug.cgi?id=1106959 qt-qsa: https://bugzilla.redhat.com/show_bug.cgi?id=1106983 R-rtracklayer: https://bugzilla.redhat.com/show_bug.cgi?id=1105923 rubygem-json: https://bugzilla.redhat.com/show_bug.cgi?id=1107150 rubygem-kgio: https://bugzilla.redhat.com/show_bug.cgi?id=1096996 rubygem-sanitize: https://bugzilla.redhat.com/show_bug.cgi?id=1107232 rubygem-session: https://bugzilla.redhat.com/show_bug.cgi?id=1107236 rubygem-term-ansicolor: https://bugzilla.redhat.com/show_bug.cgi?id=1107255 rubygem-trollop: https://bugzilla.redhat.com/show_bug.cgi?id=1107263 scim-chewing: https://bugzilla.redhat.com/show_bug.cgi?id=1107282 sugar-paint:https://bugzilla.redhat.com/show_bug.cgi?id=1107402 sugar-tamtam: https://bugzilla.redhat.com/show_bug.cgi?id=1107410 tnef: https://bugzilla.redhat.com/show_bug.cgi?id=1037361 unpaper:https://bugzilla.redhat.com/show_bug.cgi?id=1037369 urbanlightscape: https://bugzilla.redhat.com/show_bug.cgi?id=1107042 vala (for presence): https://bugzilla.redhat.com/show_bug.cgi?id=1112424 vkeybd: https://bugzilla.redhat.com/show_bug.cgi?id=1107101 wavbreaker: https://bugzilla.redhat.com/show_bug.cgi?id=1037382 xaos: https://bugzilla.redhat.com/show_bug.cgi?id=1037389 xarchiver: https://bugzilla.redhat.com/show_bug.cgi?id=1037390 xfce4-modemlights-plugin: https://bugzilla.redhat.com/show_bug.cgi?id=1037394 xfce4-screenshooter: https://bugzilla.redhat.com/show_bug.cgi?id=1107271 xfhell: https://bugzilla.redhat.com/show_bug.cgi?id=1037396 xxdiff: https://bugzilla.redhat.com/show_bug.cgi?id=1107365 znc-infobot:https://bugzilla.redhat.com/show_bug.cgi?id=1106709 Yaakov Selkowitz -- 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: F21FTBFS patches awaiting review
IMO q(pkgdb: q) lang should be obsoleted by the pure(pkgdb: pure) lang pointed out by upstream many years ago. For those compat-gcc* packages, shouldn't they be retired? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2014-07-07 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2014-07-07 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! Many thanks to Mike for running the meeting last week! I'd like to propose another this week to discuss Fedora 21 testing, though, as I had some specific stuff to bring up. Please do suggest any other relevant agenda items! == Proposed Agenda Topics == 1. Fedora 21 test planning status 2. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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: [Bug 1114497] New: odb package missing gcc-plugin
On Tue, Jul 1, 2014 at 10:04 PM, Dave Johansen davejohan...@gmail.com wrote: The simple solution to this is for me to just rebuild against 4.8.3, but upstream said that in Debian they package the GCC plugins in /usr/lib/gcc/.../x.y/plugin instead of /usr/lib/gcc/.../x.y.z/plugin so that it doesn't break when there are minor version upgrades like this. Is doing something like that possible in Fedora as well? Or should I just rebuild when there's a minor version change? Thanks, Dave I just did the rebuild and update request ( https://admin.fedoraproject.org/updates/odb-2.3.0-3.fc20?_csrf_token=7b20acd8c1590c3ef9ee27903c3ab123c6ed6cc3 ). Should I add a Requires for the current version of gcc to odb.spec? If so, is there an easy way to do that other than just hardcoding it in the file? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1067003] Review Request: perl-Time-ParseDate - Perl modules for parsing dates and time
https://bugzilla.redhat.com/show_bug.cgi?id=1067003 --- Comment #14 from Fedora Update System upda...@fedoraproject.org --- perl-Time-ParseDate-2013.1113-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Time-ParseDate-2013.1113-2.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=BTRBT6GFuDa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1067003] Review Request: perl-Time-ParseDate - Perl modules for parsing dates and time
https://bugzilla.redhat.com/show_bug.cgi?id=1067003 --- Comment #15 from Fedora Update System upda...@fedoraproject.org --- perl-Time-ParseDate-2013.1113-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Time-ParseDate-2013.1113-2.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=OYoLVi4Rlqa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1067003] Review Request: perl-Time-ParseDate - Perl modules for parsing dates and time
https://bugzilla.redhat.com/show_bug.cgi?id=1067003 --- Comment #16 from Fedora Update System upda...@fedoraproject.org --- perl-Time-ParseDate-2013.1113-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Time-ParseDate-2013.1113-2.el6 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=C3h9YrCOcMa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1067003] Review Request: perl-Time-ParseDate - Perl modules for parsing dates and time
https://bugzilla.redhat.com/show_bug.cgi?id=1067003 --- Comment #17 from Fedora Update System upda...@fedoraproject.org --- perl-Time-ParseDate-2013.1113-2.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-Time-ParseDate-2013.1113-2.el5 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=RH0ZRz0DNKa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1115913] Can't call method get_value on an undefined value at /bin/mimeopen line 162
https://bugzilla.redhat.com/show_bug.cgi?id=1115913 --- Comment #2 from Jitka Plesnikova jples...@redhat.com --- I am not able to reproduce the error. Could you please provide me output of following command? strace -ff -b execve -e trace=execve xdg-open some.png -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=XHUH4P4Bzea=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Taskotron dev and stg deployment
This has taken a bit longer than I wanted it to but we have a mostly working taskotron dev instance at: https://taskotron-dev.fedoraproject.org/ This is 100% deployed from infra's ansible repo but other than the proxy configuration for resultsdb, it should be pretty much the same thing as what's currently deployed for taskotron-stg. The only issues that I'm aware of are proxy handling issues in resultsdb_frontend: https://phab.qadevel.cloud.fedoraproject.org/T276 https://phab.qadevel.cloud.fedoraproject.org/T277 T276 needs to be fixed before we deploy to production. I can take a look at it on Monday but it would be nice to have a fix before the. For the staging env, I've gotten started on it but haven't gotten any farther than building the clients. Tomorrow is a US holiday but I'm planning to have stg deployed early next week. Tim signature.asc Description: PGP signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
