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
__
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
> 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 -- dev
> 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
F
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 pleas
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: 10
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
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
> 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
> 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/mac
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 f
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
> 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
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 tim
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:
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
> 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
>> 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
>> 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
> 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
dyn
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 uns
> 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 directl
> 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
> mi
doraproject.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 chan
vindra
- 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:
>
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
> 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
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
fal
> *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
> 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 crea
>> 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
> 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://adm
> @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
> 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 automat
> 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
> 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
> 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
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
> 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 stu
> > 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
(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
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 V
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
>> 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...
Den
> 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.or
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 ide
> 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
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:
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
--
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-too
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 contributio
51 matches
Mail list logo
