Unexpected Fedora Mass Rebuild Failures
Hi folks, We are seeing unexpected build failures in open-vm-tools package due to recent Fedora mass rebuild. I'd appreciate if you could share any insights/recommendations on https://bugzilla.redhat.com/show_bug.cgi?id=2046784. Thanks in advance, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Adding a contributor to my project
Hi folks, https://admin.fedoraproject.org/pkgdb/ is not accessible. How do I add a contributor to my project? Appreciate any help on this. Thanks in advance, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: KDE Autostart in F34
> This desktop file need to be replaced by the systemd-user unit, IMO. Thanks Vitaly. We will look into converting it to systemd-user unit. I believe that would work for all other desktop managers as well. Thanks, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: KDE Autostart in F34
> I commented in the bug with some debugging steps to try. Thanks Rex. We can discuss this further in the bug. Thanks, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
KDE Autostart in F34
Hi, I hope there are some KDE experts on the list who can help me debug this - https://bugzilla.redhat.com/show_bug.cgi?id=1953472. It looks like KDE in Fedora 34 is not honoring open-vm-tools autostart script in /etc/xdg/autostart/vmware-user.desktop. GNOME seems to work fine. Could you please confirm if KDE supports autostart scripts from /etc/xdg/autostart dir? If yes, is there a regression in F34? Thanks, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
fedpkg push failed for main
Hi, I have been maintaining open-vm-tools for several years, but never encountered this failure before. Today, I got following error for the first time: $ fedpkg push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 4 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 717 bytes | 717.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 remote: Unspecified ref refs/heads/main is blocked remote: Denied push for ref 'refs/heads/main' for user 'ravindrakumar' remote: All changes have been rejected To ssh://pkgs.fedoraproject.org/rpms/open-vm-tools ! [remote rejected] main -> main (pre-receive hook declined) error: failed to push some refs to 'ssh://ravindraku...@pkgs.fedoraproject.org/rpms/open-vm-tools' Could not execute push: Failed to execute command. Could someone please help advise me what could I do differently to address/workaround this issue? NOTE: I have also opened https://pagure.io/releng/issue/10078 issue for this. Thanks, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: libdnet in Fedora
The BuildRequires for dnet is gone now - https://src.fedoraproject.org/rpms/open-vm-tools/c/36c7fb8dfde3767b21438564ccd75d5b79bd09ee?branch=master. Thanks, Ravindra From: Oliver Falk Sent: Tuesday, January 19, 2021 3:30 AM To: Ravindra Kumar Cc: Richard W.M. Jones ; cav...@redhat.com ; libdnet-ow...@fedoraproject.org ; devel@lists.fedoraproject.org ; open-vm-tools-ow...@fedoraproject.org Subject: Re: libdnet in Fedora Hey! Right, now that you mention it, I remember I've read this already somewhere, but thanks for pointing that out! Oliver On Sat, Jan 16, 2021 at 1:16 AM Ravindra Kumar mailto:ravindraku...@vmware.com>> wrote: Thanks Rich and Oliver. FWIW, open-vm-tools 11.0.0 onwards have removed libdnet dependency - https://kojipkgs.fedoraproject.org//packages/open-vm-tools/11.0.0/2.fc32/data/logs/x86_64/build.log<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkojipkgs.fedoraproject.org%2F%2Fpackages%2Fopen-vm-tools%2F11.0.0%2F2.fc32%2Fdata%2Flogs%2Fx86_64%2Fbuild.log&data=04%7C01%7Cravindrakumar%40vmware.com%7Cbbbab87d07db4f9d750d08d8bc6db2e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637466526669719046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=jtBmR0hxo2fxHjiZ%2BP2hBQVd2OcfY%2B%2FpOp0Z8tVTlvk%3D&reserved=0>. My bad I forgot to remove libdnet from open-vm-tools.spec when I updated to 11.0.0. If no one else gets to it before me, I will remove it when I package the new open-vm-tools version 11.2.5. Thanks, Ravindra From: Oliver Falk mailto:oli...@linux-kernel.at>> Sent: Thursday, January 14, 2021 5:53 AM To: Richard W.M. Jones mailto:rjo...@redhat.com>> Cc: cav...@redhat.com<mailto:cav...@redhat.com> mailto:cav...@redhat.com>>; Ravindra Kumar mailto:ravindraku...@vmware.com>>; libdnet-ow...@fedoraproject.org<mailto:libdnet-ow...@fedoraproject.org> mailto:libdnet-ow...@fedoraproject.org>>; devel@lists.fedoraproject.org<mailto:devel@lists.fedoraproject.org> mailto:devel@lists.fedoraproject.org>>; open-vm-tools-ow...@fedoraproject.org<mailto:open-vm-tools-ow...@fedoraproject.org> mailto:open-vm-tools-ow...@fedoraproject.org>> Subject: Re: libdnet in Fedora Hey! OK... Could be that it's still in the devel branch... I'll check later! Oliver On Thu, Jan 14, 2021 at 2:51 PM Richard W.M. Jones mailto:rjo...@redhat.com>> wrote: Thanks - it all seemed to go OK. Interestingly the libdnet SONAME did not change. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones<https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fpeople.redhat.com%2F~rjones&data=04%7C01%7Cravindrakumar%40vmware.com%7Cbbbab87d07db4f9d750d08d8bc6db2e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637466526669729037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=1mLEh0gYEVEp%2B5WhtHrxKQwK9XgvGqnDnYNkTp7d2EA%3D&reserved=0> Read my programming and virtualization blog: http://rwmj.wordpress.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Frwmj.wordpress.com%2F&data=04%7C01%7Cravindrakumar%40vmware.com%7Cbbbab87d07db4f9d750d08d8bc6db2e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637466526669729037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=XzOzdbanhDc1lgYVIeIdMBJpu0EJyj99N%2F4kUA3zPoM%3D&reserved=0> virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flibguestfs.org%2Fvirt-builder.1.html&data=04%7C01%7Cravindrakumar%40vmware.com%7Cbbbab87d07db4f9d750d08d8bc6db2e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637466526669739038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=K77NxwvqBezdFO%2BO0bxGO%2BJGWOOnZ2Jv2qMpQK1HbW8%3D&reserved=0> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libdnet in Fedora
Thanks Rich and Oliver. FWIW, open-vm-tools 11.0.0 onwards have removed libdnet dependency - https://kojipkgs.fedoraproject.org//packages/open-vm-tools/11.0.0/2.fc32/data/logs/x86_64/build.log. My bad I forgot to remove libdnet from open-vm-tools.spec when I updated to 11.0.0. If no one else gets to it before me, I will remove it when I package the new open-vm-tools version 11.2.5. Thanks, Ravindra From: Oliver Falk Sent: Thursday, January 14, 2021 5:53 AM To: Richard W.M. Jones Cc: cav...@redhat.com ; Ravindra Kumar ; libdnet-ow...@fedoraproject.org ; devel@lists.fedoraproject.org ; open-vm-tools-ow...@fedoraproject.org Subject: Re: libdnet in Fedora Hey! OK... Could be that it's still in the devel branch... I'll check later! Oliver On Thu, Jan 14, 2021 at 2:51 PM Richard W.M. Jones mailto:rjo...@redhat.com>> wrote: Thanks - it all seemed to go OK. Interestingly the libdnet SONAME did not change. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones<https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fpeople.redhat.com%2F~rjones&data=04%7C01%7Cravindrakumar%40vmware.com%7C189286ba71a7461788ab08d8b893d1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637462292333742025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=XcVIOqU%2Fz6CxIEcFvDkbo9M1VGbEmSXW%2ByibGYmQpdA%3D&reserved=0> Read my programming and virtualization blog: http://rwmj.wordpress.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Frwmj.wordpress.com%2F&data=04%7C01%7Cravindrakumar%40vmware.com%7C189286ba71a7461788ab08d8b893d1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637462292333752023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=TofuBYQPWwpjSsC8AwJMqnGfR5M3VNnH08Rvaa6Dt7k%3D&reserved=0> virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flibguestfs.org%2Fvirt-builder.1.html&data=04%7C01%7Cravindrakumar%40vmware.com%7C189286ba71a7461788ab08d8b893d1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637462292333752023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=6EoWKLUN4NBAw0gnji32Hr5K%2Fnm4xlB88lgAGnqBda0%3D&reserved=0> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Question regarding systemd service unit cleanup
> You need something like this in a scriptlet: > if systemctl is-enabled A; systemctl reenable A; done > > This will remove the old links and create the new ones. Thanks Zbigniew for the idea. It seemed very promising and I tried it. Unfortunately, it still did not help because "reenable" command seems to recreate the links based on the service unit file which is newer and does not reference the dropped dependency. So, the old link to service B was still left around. The only working solution I have found is to disable service B explicitly in post install scriptlet when it is called during upgrade. Thanks, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
RE: Question regarding systemd service unit cleanup
> systemctl daemon-reload? Thanks Dridi. I had forgotten to mention that I had tried daemon-reload and that did not help. > Isn't this handled automatically by the %systemd scriptlets? %systemd_post macro is a no-op for upgrade case - https://github.com/systemd/systemd/blob/master/src/core/macros.systemd.in#L46 ($1 would be "2" for upgrade in "post" scriptlet - https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/). - Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Question regarding systemd service unit cleanup
Hi, I have removed dependency on service B from service A and all references to service B. The new package works well for fresh install (service A can be started normally), but it does not work for upgrades from previous versions where service A used to depend on service B (starting service A fails as it can't fine the service unit for service B). After upgrade from a previous version of the package, I noticed that a symlink to service B is left under /etc/system/system/A.service.requires dir that is causing the issue: # ls -l /etc/systemd/system/A.service.requires total 0 lrwxrwxrwx. 1 root root 45 Oct 8 11:10 B.service -> /usr/lib/systemd/system/B.service Basically, some cleanup is needed to remove the requires symlink that is no longer needed. Any advice/examples of such cleanup? Thanks in advance, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unable to push update
I forgot to mention that Bodhi web interface did not offer any suggestions when I typed 'open-vm-tools' package name. This was bit surprising and I could not use Bodhi web interface as a workaround. ____ From: Ravindra Kumar Sent: Thursday, August 10, 2017 3:44 PM To: Development discussions related to Fedora Subject: Re: Unable to push update > Oh wait, this is actually a bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1445294 > You need to ensure you are updated to > bodhi >= 2.6.2 > python-fedora >= 0.9.0-3.fc25 Thanks Rich. Looks like there is no bodhi package, but updating python-fedora package fixed it. Thanks, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unable to push update
> Oh wait, this is actually a bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1445294 > You need to ensure you are updated to > bodhi >= 2.6.2 > python-fedora >= 0.9.0-3.fc25 Thanks Rich. Looks like there is no bodhi package, but updating python-fedora package fixed it. Thanks, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Unable to push update
Hi, I have a new build for my package - https://koji.fedoraproject.org/koji/buildinfo?buildID=953883. However, when I try 'fedpkg update' for the new build, command fails with following error: https://gist.github.com/ravindravmw/5bbbedff0785980e5b8e3f93ef2417d6 I have tried it multiple times. I'm facing same problem for f26 branch. Could someone please let me know what am I doing wrong here? FWIW, I'm pushing a new package version from upstream and there is no bug attached to it. I have pushed package updates in the past without any bugzilla. Please let me know if missing bug in the update form could be the reason for this. Thanks, Ravindra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
RE: 'fedpkg build' hang issue
dmsimard's blog saved my day -
https://dmsimard.com/2016/12/12/updates-to-fedora-account-system-and-impacts-to-fedpkg-koji/
Thanks,
Ravindra
From: Ravindra Kumar [mailto:ravindraku...@vmware.com]
Sent: Thursday, February 16, 2017 5:02 PM
To: ad...@fedoraproject.org
Cc: devel@lists.fedoraproject.org
Subject: 'fedpkg build' hang issue
Hi,
I've been trying to run 'fedpkg build' command on rawhide and it keeps hanging.
I came across https://bugzilla.redhat.com/show_bug.cgi?id=1207178 and I have
regenerated my cert multiple times already but no luck.
I have deleted ~/.fedora and ~/.fedora*. I re-ran fedora-packager-setup and
fedora-cert commands.
When I ran 'fedpkg -v build', it gets stuck at "Initiating a koji session to
http://koji.fedoraproject.org/kojihub<https://urldefense.proofpoint.com/v2/url?u=http-3A__koji.fedoraproject.org_kojihub&d=DwMFAw&c=uilaK90D4TOVoH58JNXRgQ&r=aZsLUJKYvWoupaq4qdwhtidvOzf1DJHwbbbs8U9cmMA&m=7NwjJBonV-imNrgyn5nx6jZrbOuBDF4sm6dhH2Ap6MY&s=jOUmPtM6JhOmHO2L9IsVSLlFTFm1MYV8bBaZEwWeEa8&e=>"
for quite some time and then prints an exception backtrace.
Initiating a koji session to http://koji.fedoraproject.org/kojihub
/usr/lib/python2.7/site-packages/pyrpkg/__init__.py:309: DeprecationWarning:
BaseException.message has been deprecated as of Python 2.6
for (_, _, ssl_reason) in error.message:
You might want to run fedora-packager-setup to regenerate SSL certificate. For
more info see
https://fedoraproject.org/wiki/Using_the_Koji_build_system#Fedora_Account_System_.28FAS2.29_Setup
Could not execute build: Could not auth with koji. Login failed: [('SSL
routines', 'ssl3_get_server_certificate', 'certificate verify failed')]
Traceback (most recent call last):
File "/usr/bin/fedpkg", line 16, in
main()
File "/usr/lib/python2.7/site-packages/fedpkg/__main__.py", line 69, in main
sys.exit(client.args.command())
File "/usr/lib/python2.7/site-packages/pyrpkg/cli.py", line 939, in build
sets, nvr_check)
File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 1846, in
build
build_target = self.kojisession.getBuildTarget(self.target)
File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 469, in
kojisession
self.load_kojisession()
File "/usr/lib/python2.7/site-packages/fedpkg/__init__.py", line 315, in
load_kojisession
return super(Commands, self).load_kojisession(anon)
File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 316, in
load_kojisession
'failed: %s' % error)
pyrpkg.errors.rpkgAuthError: Could not auth with koji. Login failed: [('SSL
routines', 'ssl3_get_server_certificate', 'certificate verify failed')]
Anyone else faced it?
Any suggestions about what could be wrong with my cert.
Thanks,
Ravindra
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
'fedpkg build' hang issue
Hi,
I've been trying to run 'fedpkg build' command on rawhide and it keeps hanging.
I came across https://bugzilla.redhat.com/show_bug.cgi?id=1207178 and I have
regenerated my cert multiple times already but no luck.
I have deleted ~/.fedora and ~/.fedora*. I re-ran fedora-packager-setup and
fedora-cert commands.
When I ran 'fedpkg -v build', it gets stuck at "Initiating a koji session to
http://koji.fedoraproject.org/kojihub"; for quite some time and then prints an
exception backtrace.
Initiating a koji session to http://koji.fedoraproject.org/kojihub
/usr/lib/python2.7/site-packages/pyrpkg/__init__.py:309: DeprecationWarning:
BaseException.message has been deprecated as of Python 2.6
for (_, _, ssl_reason) in error.message:
You might want to run fedora-packager-setup to regenerate SSL certificate. For
more info see
https://fedoraproject.org/wiki/Using_the_Koji_build_system#Fedora_Account_System_.28FAS2.29_Setup
Could not execute build: Could not auth with koji. Login failed: [('SSL
routines', 'ssl3_get_server_certificate', 'certificate verify failed')]
Traceback (most recent call last):
File "/usr/bin/fedpkg", line 16, in
main()
File "/usr/lib/python2.7/site-packages/fedpkg/__main__.py", line 69, in main
sys.exit(client.args.command())
File "/usr/lib/python2.7/site-packages/pyrpkg/cli.py", line 939, in build
sets, nvr_check)
File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 1846, in
build
build_target = self.kojisession.getBuildTarget(self.target)
File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 469, in
kojisession
self.load_kojisession()
File "/usr/lib/python2.7/site-packages/fedpkg/__init__.py", line 315, in
load_kojisession
return super(Commands, self).load_kojisession(anon)
File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 316, in
load_kojisession
'failed: %s' % error)
pyrpkg.errors.rpkgAuthError: Could not auth with koji. Login failed: [('SSL
routines', 'ssl3_get_server_certificate', 'certificate verify failed')]
Anyone else faced it?
Any suggestions about what could be wrong with my cert.
Thanks,
Ravindra
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: The official way to upgrade F18 to F19
> If folks think we shouldn't make 'fedup --network 19' work now to > upgrade people to branched/prerelease, please scream. ;) Otherwise it > will be the case from now on. Probably, 'fedup --network 19' should not install alpha/beta releases automatically, instead a switch to specifically select a prerelease would be a better choice. That gives more control to the user. I mean 19 should mean Fedora 19 and may be you could use something like 19a/19alpha, 19b/19beta etc for alpha, beta releases respectively. Or, just 19pre for latest prerelease to be simpler. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
>> No, I was not thinking of reboot/RPM changing anything already >> installed. I was referring to DB solution as static because >> it would stick one configuration forever. Instead, I was >> thinking of RPM to always base its decision on the environment >> where it is running at that point of time and provide a way >> to override RPM behavior so that advanced users can make a >> choice. > > This is the logic windows installers use but I don't think it's the > correct one. The installer should never change behaviour based on a system > state that can change over time (unless this state is under its control > which is not the case here) I think of this like two categories of machine: 1. Systems that will not change the environment for a very long time and continue to run in either a physical or a virtual environment. 2. Systems that will change the runtime environment occasionally. DB approach works for #1 and fails miserably for #2 (example below). At the same time runtime detection approach works for #1 and works almost right for #2 with few exceptions. Exceptions can be addressed through an override switch. Example: Fedora image running in 'X' virtual environment is moved to 'Y' virtual environment. If 'X' is sticking in the RPM DB, packages intended for 'Y' can't be installed because RPM DB thinks otherwise. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
>> Having a fake package in DB makes it very static. I think a >> dynamic (evaluated each time rpm commands are run) implementation >> will be more useful for the cases like P2V and V2V. > The problem I see here is that you can boot the same OS on different > hypervisors or (with P2V) transfer it from physical to virtual. > Should RPM start (un-)installing things when this happens? Could a > reboot result in broken dependencies? No, I was not thinking of reboot/RPM changing anything already installed. I was referring to DB solution as static because it would stick one configuration forever. Instead, I was thinking of RPM to always base its decision on the environment where it is running at that point of time and provide a way to override RPM behavior so that advanced users can make a choice. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
> libsolv/yast does it ( if I understood correctly ).You can have some > virtual provides that exist as fake packages in the db, and then have a > package have a requires on it. So it cannot be installed if the hardware > is not here. Having a fake package in DB makes it very static. I think a dynamic (evaluated each time rpm commands are run) implementation will be more useful for the cases like P2V and V2V. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
I don't know if this feature already exists, so forgive my ignorance if it is already there. I think having an RPM equivalent of Systemd's "ConditionVirtualization" will be very useful for controlling packages that are intended for virtualized environments. It could gracefully warn users about unsupported environments. It can also be overridden using some switch to force ignore the warning. For example, it would be very clean to say if I can specify "Requires: ConditionVirtualization=vmware" to disallow my RPM installation on non-VMware environments and at the same time have a switch to force install in case that is what I really want to do because I'm building an image for different runtime environment. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding new group to comps-f19.xml.in
> Well, if comps groups can't subsume other comps groups, that rather > seems to suck. The 'have these groups included in @standard and @base-x' > approach seemed by quite a long margin the best one; the alternatives > all seem to suck. In the current situation, the closest we could get is directly including these packages in the packagelist for @standard and @base-x groups. But, that has its own drawbacks :-( Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding new group to comps-f19.xml.in
> I thought the intent was to have the groups themselves included in other > groups; virt-agents in 'standard' and 'virt-agents-x' in 'base-x'. They > would then be installed by default in most configurations, but could be > specifically left out via a kickstart if desired, and would not be in > minimal installs. I too like that approach. But, I think this does not work. FYI, when I proposed adding new groups to 'standard' and 'base-x' groups, but I got following comment from Bill. "grouplist is not something that actually is used, though; they would need to either be added as mandatory/optional groups to the desktop environments, or just brought in via the spins' kickstart files.'" Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding new group to comps-f19.xml.in
Thanks Bill. No issues with the checkin. I looked at the checked in files and I have following questions: 1. "false" and "false" elements will make these packages not to be installed by default and invisible to users. Then, how would it be installed? 2. We have open-vm-tools-devel package and I think it will make sense to include it in "developer-workstation-environment". What do you say? Thanks, Ravindra - Original Message - From: "Bill Nottingham" To: "Development discussions related to Fedora" Cc: tr...@lists.fedoraproject.org Sent: Monday, May 20, 2013 1:48:47 PM Subject: Re: Adding new group to comps-f19.xml.in Ravindra Kumar (ravindraku...@vmware.com) said: > Please let me know when can I checkin this change. Oops, my apologies. I got the OK from the translation list, so I checked in the change already. Hope that's not a problem. I added spice-vdagent and qemu-guest-agent where appropriate to the groups, and I'll tweak the kickstart files that make the spins next. Bill > > Thanks, > Ravindra > > - Original Message - > From: "Bill Nottingham" > To: "Development discussions related to Fedora" > > Cc: tr...@lists.fedoraproject.org > Sent: Tuesday, May 14, 2013 12:51:45 PM > Subject: Re: Adding new group to comps-f19.xml.in > > Ravindra Kumar (ravindraku...@vmware.com) said: > > > The two added group are OK. grouplist is not something that actually is > > > used, though; they would need to either be added as mandatory/optional > > > groups to the desktop environments, or just brought in via the spins' > > > kickstart files. > > > > > Also, please attach patches - your mailer appears to have mangled the > > > spacing. > > > > Thanks Bill for looking at it. Could you please take a look at the new > > patch (attached)? > > Seems initially reasonable, might tweak the names/descriptions a bit > (the names need to be distinct). > > That being said, this would be a string freeze. CC'ing the translation > list - OK to add these two groups to comps for F-19? > > > I would appreciate if you could let me know a way to test comps file > > changes. > > Will follow up on devel@ only with this. > > Bill > > > > --- comps-f19.xml.in2013-05-10 19:00:24.191468344 -0700 > > +++ comps-f19.xml.in.new2013-05-12 21:49:31.433352612 -0700 > > @@ -5633,6 +5633,26 @@ > > > > > > > > +virt-agents > > +<_name>Virtualization Agents > > +<_description>These packages enable better management of virtual > > machines. > > +true > > +true > > + > > + open-vm-tools > > + > > + > > + > > +virt-agents-x > > +<_name>Virtualization Agents > > +<_description>These packages enable better user experience for virtual > > machines. > > +true > > +true > > + > > + open-vm-tools-desktop > > + > > + > > + > > virtualization > > <_name>Virtualization > > <_description>These packages provide a virtualization > > environment. > > @@ -5878,6 +5898,8 @@ > >hardware-support > >printing > >firefox > > + virt-agents > > + virt-agents-x > >gnome-desktop > > > > > > @@ -5902,6 +5924,8 @@ > >multimedia > >hardware-support > >printing > > + virt-agents > > + virt-agents-x > >kde-desktop > > > > > > @@ -5928,6 +5952,8 @@ > >multimedia > >hardware-support > >printing > > + virt-agents > > + virt-agents-x > >xfce-desktop > >xfce-apps > >xfce-media > > @@ -5953,6 +5979,8 @@ > >multimedia > >hardware-support > >printing > > + virt-agents > > + virt-agents-x > >lxde-desktop > > > > > > @@ -5977,6 +6005,8 @@ > >multimedia > >hardware-support > >printing > > + virt-agents > > + virt-agents-x > >cinnamon-desktop > > > > > > @@ -5998,6 +6028,8 @@ > >multimedia > >hardware-support > >printing > > + virt-agents > > + virt-agents-x > >mate-desktop > > > > > > @@ -6019,
Re: Adding new group to comps-f19.xml.in
Addressed all comments from Bill and also renamed groups (virt-agents -> guest-agents, virt-agents-x -> guest-desktop-agents). Attached are updated patches and following are test results: [root@localhost yum.repos.d]# yum groupinfo guest-agents Loaded plugins: langpacks, refresh-packagekit There is no installed groups file. Group: Guest Agents Group-Id: guest-agents Description: Agents used when running under a hypervisor. Default Packages: open-vm-tools [root@localhost yum.repos.d]# yum groupinfo guest-desktop-agents Loaded plugins: langpacks, refresh-packagekit There is no installed groups file. Group: Guest Desktop Agents Group-Id: guest-desktop-agents Description: Agents used when running as a virtualized desktop. Default Packages: open-vm-tools-desktop [root@localhost yum.repos.d]# Please let me know when can I checkin this change. Thanks, Ravindra - Original Message - From: "Bill Nottingham" To: "Development discussions related to Fedora" Cc: tr...@lists.fedoraproject.org Sent: Tuesday, May 14, 2013 12:51:45 PM Subject: Re: Adding new group to comps-f19.xml.in Ravindra Kumar (ravindraku...@vmware.com) said: > > The two added group are OK. grouplist is not something that actually is > > used, though; they would need to either be added as mandatory/optional > > groups to the desktop environments, or just brought in via the spins' > > kickstart files. > > > Also, please attach patches - your mailer appears to have mangled the > > spacing. > > Thanks Bill for looking at it. Could you please take a look at the new > patch (attached)? Seems initially reasonable, might tweak the names/descriptions a bit (the names need to be distinct). That being said, this would be a string freeze. CC'ing the translation list - OK to add these two groups to comps for F-19? > I would appreciate if you could let me know a way to test comps file > changes. Will follow up on devel@ only with this. Bill > --- comps-f19.xml.in 2013-05-10 19:00:24.191468344 -0700 > +++ comps-f19.xml.in.new 2013-05-12 21:49:31.433352612 -0700 > @@ -5633,6 +5633,26 @@ > > > > +virt-agents > +<_name>Virtualization Agents > +<_description>These packages enable better management of virtual > machines. > +true > +true > + > + open-vm-tools > + > + > + > +virt-agents-x > +<_name>Virtualization Agents > +<_description>These packages enable better user experience for virtual > machines. > +true > +true > + > + open-vm-tools-desktop > + > + > + > virtualization > <_name>Virtualization > <_description>These packages provide a virtualization > environment. > @@ -5878,6 +5898,8 @@ >hardware-support >printing >firefox > + virt-agents > + virt-agents-x >gnome-desktop > > > @@ -5902,6 +5924,8 @@ >multimedia >hardware-support >printing > + virt-agents > + virt-agents-x >kde-desktop > > > @@ -5928,6 +5952,8 @@ >multimedia >hardware-support >printing > + virt-agents > + virt-agents-x >xfce-desktop >xfce-apps >xfce-media > @@ -5953,6 +5979,8 @@ >multimedia >hardware-support >printing > + virt-agents > + virt-agents-x >lxde-desktop > > > @@ -5977,6 +6005,8 @@ >multimedia >hardware-support >printing > + virt-agents > + virt-agents-x >cinnamon-desktop > > > @@ -5998,6 +6028,8 @@ >multimedia >hardware-support >printing > + virt-agents > + virt-agents-x >mate-desktop > > > @@ -6019,6 +6051,8 @@ >input-methods >multimedia >hardware-support > + virt-agents > + virt-agents-x >sugar-desktop > > > @@ -6051,6 +6085,8 @@ >gnome-software-development >kde-software-development >x-software-development > + virt-agents > + virt-agents-x >virtualization >web-server > > @@ -6084,6 +6120,7 @@ >standard >core >hardware-support > + virt-agents >web-server > > > @@ -6108,6 +6145,7 @@ >standard >core >hardware-support > + virt-agents > > >dogtag > @@ -6138,6 +6176,8 @@ >fonts >hardware-support >mu
Fwd: Adding new group to comps-f19.xml.in
Including mailing list for wider/more inputs. >> I'm thinking of another approach. How about adding "open-vm-tools" >> to "standard" group and "open-vm-tools-desktop" to "base-x" group? >> Then, I will not have to modify so many installation environments >> (patches attached). In future, we could make these packages >> conditional by modifying Anaconda to support something like >> following. > Assorted people on the list didn't like this idea, so I'd prefer > not to go that route. As well: >> > requiredvirtualization="vmware">open-vm-toolspackagereq> > ... that's not going to happen. We want to eliminate these > conditionals wherever possible - we're not going to add new ones. Bill and I are discussing following two approaches for including open-vm-tools in Fedora: 1. Create two new groups, 'virt-agents' with 'open-vm-tools' and 'virt-agents-x' with 'open-vm-tools-desktop'. Add 'virt-agents' group to X/non-X environments and add 'virt-agents-x' group to X environments. 2. Add 'open-vm-tools' to 'standard' group and add 'open-vm-tools-desktop' to 'base-x' group. Last time when I discussed this, people did not like adding stuff to 'core', but there was a suggestion to put it in 'standard'. Therefore, I would like to know what people think about approach #2. Does anyone have any comments/inputs for one approach over another? Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding new group to comps-f19.xml.in
> The two added group are OK. grouplist is not something that actually is > used, though; they would need to either be added as mandatory/optional > groups to the desktop environments, or just brought in via the spins' > kickstart files. > Also, please attach patches - your mailer appears to have mangled the > spacing. Thanks Bill for looking at it. Could you please take a look at the new patch (attached)? I would appreciate if you could let me know a way to test comps file changes. Thanks, Ravindra--- comps-f19.xml.in 2013-05-10 19:00:24.191468344 -0700 +++ comps-f19.xml.in.new 2013-05-12 21:49:31.433352612 -0700 @@ -5633,6 +5633,26 @@ +virt-agents +<_name>Virtualization Agents +<_description>These packages enable better management of virtual machines. +true +true + + open-vm-tools + + + +virt-agents-x +<_name>Virtualization Agents +<_description>These packages enable better user experience for virtual machines. +true +true + + open-vm-tools-desktop + + + virtualization <_name>Virtualization <_description>These packages provide a virtualization environment. @@ -5878,6 +5898,8 @@ hardware-support printing firefox + virt-agents + virt-agents-x gnome-desktop @@ -5902,6 +5924,8 @@ multimedia hardware-support printing + virt-agents + virt-agents-x kde-desktop @@ -5928,6 +5952,8 @@ multimedia hardware-support printing + virt-agents + virt-agents-x xfce-desktop xfce-apps xfce-media @@ -5953,6 +5979,8 @@ multimedia hardware-support printing + virt-agents + virt-agents-x lxde-desktop @@ -5977,6 +6005,8 @@ multimedia hardware-support printing + virt-agents + virt-agents-x cinnamon-desktop @@ -5998,6 +6028,8 @@ multimedia hardware-support printing + virt-agents + virt-agents-x mate-desktop @@ -6019,6 +6051,8 @@ input-methods multimedia hardware-support + virt-agents + virt-agents-x sugar-desktop @@ -6051,6 +6085,8 @@ gnome-software-development kde-software-development x-software-development + virt-agents + virt-agents-x virtualization web-server @@ -6084,6 +6120,7 @@ standard core hardware-support + virt-agents web-server @@ -6108,6 +6145,7 @@ standard core hardware-support + virt-agents dogtag @@ -6138,6 +6176,8 @@ fonts hardware-support multimedia + virt-agents + virt-agents-x basic-desktop @@ -6163,6 +6203,7 @@ standard + virt-agents -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Adding new group to comps-f19.xml.in
Hi Bill and others, Based on the earlier discussions in the emails, I have following diff for comps-f19.xml.in: --- comps-f19.xml.in 2013-04-29 17:41:10.003026000 -0700 +++ comps-f19.xml.in.new 2013-05-08 20:35:57.000112000 -0700 @@ -7,6 +7,9 @@ <_description>Local X.org display server false false + + virt-agents-x + xorg-x11-drv-ati xorg-x11-drv-evdev @@ -1150,6 +1153,9 @@ <_description>Common set of utilities that extend the minimal installation. false false + + virt-agents + acl at @@ -5633,6 +5639,26 @@ + virt-agents + <_name>Virtualization Agents + <_description>These packages enable better management of virtual machine. + true + true + + open-vm-tools + + + + virt-agents-x + <_name>Virtualization Agents + <_description>These packages enable better user experience for virtual machine. + true + true + + open-vm-tools-desktop + + + virtualization <_name>Virtualization <_description>These packages provide a virtualization environment. Could you please confirm if this is what you are expecting and how to test it? Wiki page http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups says nothing about testing apart from running 'xsltproc'. I ran 'xsltproc' and it does not say anything about a 'group' containing a 'grouplist', so I'm not sure if this will work or not. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
> *but* please undersatdn with your argumentation a lot of maintainers > could claim that their packages are in CORE for several reasons > because they are expected to be used from most users > please leave core be what core means > and as i clearly statet that i have open-vm-tools on nearly any > of my setups please respect that i try to speak for other users > which are not using VMware I got your point. I will follow the approach of creating a new group as suggested by Bill. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
> Well, no, that means it precisely *is* an issue :) that adds > open-vm-tools to the list of reasons we might want to have two > virt-agents groups, call them virt-agents and virt-agents-x or > something. You'd want open-vm-tools to be in one and open-vm-tools-x to > be in the other. I meant creating two groups is not an issue. In fact, we had this in our mind when we split it into two packages. We intended X related package specifically for desktops. > What we do with the groups is another question; there are various > options. We could just put the 'virt-agents' group in the 'standard' > group and the 'virt-agents-x' group in the 'base-x' group, for instance. > Or we could add them directly to other groups. Bill's the expert here, > though. Sounds good to me. My only concern is, can we add a grouplist to a group? Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
>> Perhaps a virt-agents group that contains open-vm-tools, hypervkvpd, >> qemu-guest-agent, etc? > Right, I was just thinking down those lines. Create such a group, and > have it installed by default. Makes sure the tools are available in most > cases, but not in minimal installs, and allows them to be easily added > or removed in any other config. I think I can do this, but this means I will have to include the new group in all the other configs? Will I be allowed to make that change in comps file? > Only problem is it might need to be at least two groups, for an X/non-X > split. Right now, for instance, spice-vdagent is in the base-x group, > because all its functions are X-related, so there's no point having it > installed if you don't have X in the guest. This is not an issue for open-vm-tools. open-vm-tools X components are already packaged separately as open-vm-tools-desktop. My plan was to include open-vm-tools-desktop in a common desktop config like gnome and kde. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
> Keep in mind that @standard is just that -- installed as part of every > normal install. Ok, I think it should work open-vm-tools. Do I make the changes to comps or do I need to raise a bug for 'comps' maintainer? Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
> @core is supposed to be the minimum functional install. It is my > understanding that, even under VMWare, open-vm-tools is not required for > the system to be functional, so open-vm-tools does not belong in @core. It is not required for system to be functional, but it also leaves a significant gap in the VM to be fully operational unless Tools are installed. I listed out a bunch of functionality that depends on open-vm-tools in my other response. If there are strong use cases that don't require that functionality then probably it makes sense to not be part of core, otherwise, I think it makes more sense to make open-vm-tools part of @core because sooner or later users will end up installing these due to one or the other use case. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
> and why? open-vm-tools are required for anything that requires co-ordination with the guest. Here are a few examples, clean shutdown of guest from VM management interface, guest consistent snapshots, collection/display of guest resource usage information in VM management interface, guest automation (running commands inside guest) and other features VDR/HA as you mentioned. > why should anybody need openvm-tools on a non VMware guest? I believe for P2V and V2V use cases. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
> It might help to elaborate your reasoning. @core is going to be used by > people trying to make minimal installs (with exactly what they need on > top). It is hard to see why open-vm-tools would be considered necessary > to every Fedora install. @standard would seem to make more sense I feel so because of P2V use cases. I think it is a very small price of little disk space you pay to avoid making any install changes later on. In order to make open-vm-tools easy to install in most of the environments, we have done a bunch of things. 1. We have split it in multiple packages. Drivers have been taken out and separately upstreamed in Linux kernel. User space components have been split into two packages open-vm-tools (useful for servers and desktops) and open-vm-tools-desktop (useful for desktops). open-vm-tools-desktop clearly falls in the category of optional package. So, @standard seems appropriate for this. 2. In order to make open-vm-tools suitable for physical and non-VMware environments, we have made it a no-op on all non-VMware environments. Given above points, the only bad side effect I can think of is the disk space open-vm-tools package takes. If someone can come up with any other bad side effects, I will be happy to address that. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
> I think it's probably really better in the "@standard" package group, which > is one step up from core. People who want a minimal installation but know > they'll be in vmware can add it directly. Thanks Matthew. I think @standard package should work. Could you please help me with the process? I don't really see anything mentioned about it in this document, https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups. Thinking more about it. I believe ideal will be to add 'open-vm-tools' to the @core group and add 'open-vm-tools-desktop' to the @standard group. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
> I think it's probably really better in the "@standard" package group, which > is one step up from core. People who want a minimal installation but know > they'll be in vmware can add it directly. Thanks Matthew. I think @standard package should work. Could you please help me with the process? I don't really see anything mentioned about it in this document, https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
Just picking the latest mail on this thread. >> I don't see why we would add this by default, the VM will function >> without is (unlike storage) and we don't add ovirt-guest-agent and >> other virt vendor's agents by default. > We do, in fact, include the SPICE agent stuff by default now. (Which I > like because it means copy/paste out of Fedora KVMs always works, but I > never claimed not to be a hypocrite :>) I think there are opinions in favor as well as against including open-vm-tools to core group. However, I'm not sure if there is a convincing explanation for following issues with conditional install of open-vm-tools: 1. Given that DVD image will not have open-vm-tools, installing these by default inside a VM will not be possible when VM is not connected to network or VM is running behind a proxy. 2. All the usecases where install environment is not the same as execution environment (including P2V) will have poor install experience. 3. Installer (Anaconda) will have to be modified specifically for each virtualization solution. Given that open-vm-tools is not a large package and is a no-op on physical, what are the real obstacles in putting it in core? Or, in other words, what would it take to put it in core group? If it is absolute no, I would proceed with the Anaconda patch if there is a good explanation/alternative to the 3 issues I have listed above. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
> the open-vm-tools should be generally be splitted in packages > with and without X11 deps - below my personal SPEC file for > a fedora infrastructure on top of vSphere with all things you > need for "VMware DataRecovery"-backups and VMware-HighAbility > > you do not want any X11-deps and HGFS stuff on production sevrers We have split open-vm-tools in 3 RPMS: http://koji.fedoraproject.org/koji/buildinfo?buildID=415709 open-vm-tools-9.2.3-4.fc19.i686.rpm - This is very much like what your spec file will generate open-vm-tools-desktop-9.2.3-4.fc19.i686.rpm - This is all related UI stuff open-vm-tools-devel-9.2.3-4.fc19.i686.rpm - This is for developing stuff with virtualization Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
> > I can't see, how this can happen anyways. Anaconda just runs once (at > > installation), afterwards it can safely be removed (correct me, if I'm > > wrong). > > > > Could you please explain, why this should be useful for all our users? I > > think it's more sensible to install, when running on VMware. And also: > > why do you require this at all? > > > Rather than trying to only install it in particular scenarios, it is > better to install it everywhere and then make sure that it is a no-op > unless it is running inside VMWare. Not least because if we're building > a cloud image, the initial build environment likely won't involve VMware > at all, but the ultimate runtime environment may well be VMWare. I was thinking about this approach but the only downside is physical deployments and non-VMware VMs. I'm not sure if it is common to install unused packages on system. > The systemd unit file open-vm-tools includes already has a statement > ConditionVirtualization=vmware. Whether there is more work required > to make sure the package is a no-op on non-VMWare deployments is > something that'd need to be verified before inclusion in the core > package group. Yes, vmtoolsd service is a no-op in all non-VMware environments. In fact, it will simply exit even if systemd check is not there, because we do a platform check inside before starting the main loop. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
(Batching a bunch of replies) > Install and uninstall looks a bit weird to me; what could be > done is to make the package conditionally whether it's running > in a VMware VM or not, much like it happens now for the EFI > packages (only installed on an EFI system) or the spice agent > (IIRC) if it's installed in libvirt/kvm or RHEV/ovirt. Thanks Simone. I will look into this. > Wouldn't the opposite make more sense? Yes, that is more logical. But, I have considered how Anaconda installs packages from CD and yum etc. Conditionally excluding it during different types of installation methods will probably require lots of changes in different pieces of install framework. E.g. including/excluding a package from CD, including/excluding a package from yum etc. > > How does this work together with VMwares hint, to remove > > open-vm-tools distributed by linux distributions at all? > > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1013096 > > > Yeah. This is quite confusing. VMWare folks are pushing > for better integration but unless VMWare stops putting out > conflicting messages, I am not sure anyone benefits. I don't really see what is conflicting in the KB article. There are two things to note here. 1. This KB article is not discouraging usage of open-vm-tools as such but it just describes a solution to install VMware Tools when open-vm-tools are already installed. Currently, it is not advised to have both packages installed together (this is changing, please see my note below). VMware Tools are more feature rich than open-vm-tools, so there are cases where VMware Tools are needed and therefore open-vm-tools have to be replaced with VMware Tools to get the desired functionality. 2. Our current plan is to support open-vm-tools in multiple ways, e.g. allow VMware Tools to co-exist with open-vm-tools, and fill the feature gaps in open-vm-tools. We are working on it and we will update the relevant KB articles as we make progress. Hope this clarifies a bit. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Adding open-vm-tools to core group
Hi, It is going to very useful for users if we install open-vm-tools inside a VM on VMware always. For this, I'm proposing following design: 1. Add open-vm-tools to the core package group 2. Modify Anaconda to uninstall open-vm-tools after installation if install is not running on a VM on VMware Could someone from Minimal Core SIG please help me through the process to make this change? Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Updating SRPM for rawhide
Hi, After my changes today, the latest SRPM should be "open-vm-tools-9.2.3-3.fc20.src.rpm" instead of open-vm-tools-9.2.3-1.fc20.src.rpm . Could someone please tell me how do I get this page http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/source/SRPMS/o/ updated? Thanks in advance, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Login to Koji
>> Hopefully, last problem is how do I specify proxy for koji commands? >> Does it not support proxies? I found this being asked earlier, >> http://www.redhat.com/archives/rhl-devel-list/2008-August/msg00667.html? kevin> I think it uses the normal http_proxy and https_proxy env variables... Dennis> Koji doesnt support proxies. the ssl code opens sockets directly I think Dennis is right. Even after setting proxy env vars, koji is not able to connect. Given that I have to do it from behind a proxy, what is the alternative for me in this case? Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Login to Koji
> We are adjusting anything that tells you you need to set this up. > Where did you see it? From fedora-packager-setup? Yes. It generates a cert for browser and asks it to be imported in the browser. BTW, fedora-packager-setup has not generated ~/.koji directory for me, https://fedoraproject.org/wiki/Using_the_Koji_build_system#Koji_Config Hopefully, last problem is how do I specify proxy for koji commands? Does it not support proxies? I found this being asked earlier, http://www.redhat.com/archives/rhl-devel-list/2008-August/msg00667.html? Thanks in advance, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Login to Koji
Hi, I have setup my certificate today using "fedora-packager-setup". However, when I try to login to https://koji.fedoraproject.org/koji/ after importing "fedora-browser-cert.p12" into Firefox, it keeps timing out. I have tried with Firefox 19.0.2 on Windows and 17.0.1 on Fedora 18. Any ideas what could be the problem? Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using fedora-packager-setup behind a proxy
> This looks like a bug that we recently closed in python-requests. See if > there's an update for that package available. Thanks Toshio. "yum update python-requests" solved it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using fedora-packager-setup behind a proxy
Thanks Toshio, "https_proxy=" helped me to go little further. I got a
different error, here is the traceback:
Traceback (most recent call last):
File "/usr/bin/fedora-packager-setup", line 108, in
main()
File "/usr/bin/fedora-packager-setup", line 82, in main
fedora_cert.create_user_cert()
File "/usr/lib/python2.7/site-packages/fedora_cert/__init__.py", line 96, in
create_user_cert
cert = fas.user_gencert()
File "/usr/lib/python2.7/site-packages/fedora/client/fas2.py", line 731, in
user_gencert
request = self.send_request('user/dogencert', auth=True)
File "/usr/lib/python2.7/site-packages/fedora/client/baseclient.py", line
344, in send_request
auth_params=auth_params, retries=retries)
File "/usr/lib/python2.7/site-packages/fedora/client/proxyclient.py", line
394, in send_request
if 'exc' in data:
TypeError: argument of type 'NoneType' is not iterable
I also got a mail from fedoraproject.org that a certificate has been generated
for me.
FWIW, I get the following traceback if I provide one of "all_proxy=" or
"http_proxy=" or "proxy=":
Traceback (most recent call last):
File "/usr/bin/fedora-packager-setup", line 108, in
main()
File "/usr/bin/fedora-packager-setup", line 82, in main
fedora_cert.create_user_cert()
File "/usr/lib/python2.7/site-packages/fedora_cert/__init__.py", line 96, in
create_user_cert
cert = fas.user_gencert()
File "/usr/lib/python2.7/site-packages/fedora/client/fas2.py", line 731, in
user_gencert
request = self.send_request('user/dogencert', auth=True)
File "/usr/lib/python2.7/site-packages/fedora/client/baseclient.py", line
344, in send_request
auth_params=auth_params, retries=retries)
File "/usr/lib/python2.7/site-packages/fedora/client/proxyclient.py", line
351, in send_request
verify=not self.insecure,
File "/usr/lib/python2.7/site-packages/requests/api.py", line 98, in post
return request('post', url, data=data, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/safe_mode.py", line 39, in
wrapped
return function(method, url, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/api.py", line 51, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 241, in
request
r.send(prefetch=prefetch)
File "/usr/lib/python2.7/site-packages/requests/models.py", line 632, in send
raise ConnectionError(sockerr)
requests.exceptions.ConnectionError: [Errno 101] Network is unreachable
Thanks,
Ravindra
- Original Message -
From: "Toshio Kuratomi"
To: "Development discussions related to Fedora"
Sent: Friday, April 12, 2013 3:01:38 PM
Subject: Re: Using fedora-packager-setup behind a proxy
On Fri, Apr 12, 2013 at 11:59:21PM +0400, Alexey I. Froloff wrote:
> On Fri, Apr 12, 2013 at 12:42:25PM -0700, Ravindra Kumar wrote:
> > I keep getting network connection failures even after I specify
> > HTTP_PROXY or ALL_PROXY env vars.
> Shouldn't it be "http_proxy" and "all_proxy", in lower case?
I suspect https_proxy is what's needed (although seeing the traceback would
help diagnose :-)
-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Using fedora-packager-setup behind a proxy
Hi, Has someone used fedora-packager-setup behind a proxy successfully? I keep getting network connection failures even after I specify HTTP_PROXY or ALL_PROXY env vars. Google is also not giving good suggestions. Could you please suggest me any way to work around it? Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Thanks Rahul. Given that Simone has already accepted existing bug for review, I will create a new bug if he is ok with that. Does that sound ok? Thanks, Ravindra - Original Message - From: "Rahul Sundaram" To: "Development discussions related to Fedora" Sent: Tuesday, April 9, 2013 8:32:26 AM Subject: Re: Self Introduction Hi On Tue, Apr 9, 2013 at 1:59 AM, Ravindra Kumar < ravindraku...@vmware.com > wrote: Hi all, I work for VMware. My Fedora account name is "ravindrakumar". I would like to contribute open-vm-tools package to ongoing development of Fedora 19. For more details about open-vm-tools project, please refer http://open-vm-tools.sourceforge.net/ . My review request for this contribution can be tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=905255#c6 This is going to be my first contribution to Fedora, so I need a sponsor for my contribution. I would really appreciate if someone could review my work and sponsor me. Welcome to Fedora. If you are taking over from someone else, please file a new review request and close the existing one as duplicate. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hi all, I work for VMware. My Fedora account name is "ravindrakumar". I would like to contribute open-vm-tools package to ongoing development of Fedora 19. For more details about open-vm-tools project, please refer http://open-vm-tools.sourceforge.net/. My review request for this contribution can be tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=905255#c6 This is going to be my first contribution to Fedora, so I need a sponsor for my contribution. I would really appreciate if someone could review my work and sponsor me. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
