yum update -- F16-latest => rawhide
Heya, I'm trying to get rawhide running by yum updating a minimal footprint F16 virtual machine. Only @core package, so no gnome-* nothing else. Here is some info: # [root@dhcp201-139 ~]# cat /etc/redhat-release Fedora release 16 (Verne) [root@dhcp201-139 ~]# # [root@dhcp201-139 ~]# yum --disablerepo=* --enablerepo=rawhide update . . . . Installing for dependencies: groff-base x86_64 1.21-5.fc17 rawhide 783 k p11-kit x86_64 0.6-1.fc17 rawhide 33 k perl-Carpnoarch 1.22-1.fc17 rawhide 16 k Transaction Summary === Install 6 Packages Upgrade 197 Packages Remove1 Package Total size: 108 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 Please report this error in http://yum.baseurl.org/report You could try running: rpm -Va --nofiles --nodigest Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx-2011-10-11-05-27lkgwPY.yumtx # Then I tried: # [root@dhcp201-139 ~]# rpm -Va --nofiles --nodigest [root@dhcp201-139 ~]# # Tried to clean-up the yum cache, rpm dbs: # [root@dhcp201-139 ~]# rm -rf /var/cache/yum/* [root@dhcp201-139 ~]# rm -rf /var/lib/rpm/__db* [root@dhcp201-139 ~]# rpm --rebuilddb # Then re-tried : [root@dhcp201-139 ~]# yum --disablerepo=* --enablerepo=rawhide update Still no dice. As it still throws -- 'ERROR with transaction check vs depsolve:' Any hints here? Meanwhile, I tried to install a clean f16 minimal guest on a latest f16 host, and it just hung. Details, I posted to fedora-virt list here - http://lists.fedoraproject.org/pipermail/virt/2011-October/002933.html -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum update -- F16-latest => rawhide
On 10/11/2011 05:29 PM, Michael Schwendt wrote: > On Tue, 11 Oct 2011 17:19:22 +0530, KC (Kashyap) wrote: > >> Heya, >> >> I'm trying to get rawhide running by yum updating a minimal footprint F16 >> virtual >> machine. Only @core package, so no gnome-* nothing else. > > And no /bin/sh either? It is provided by "bash". That was the obvious check. I /did/ check that (forgot to mention) ## [root@dhcp201-139 ~]# ls -al /bin/sh lrwxrwxrwx. 1 root root 4 Oct 10 15:20 /bin/sh -> bash ## [root@dhcp201-139 ~]# file /bin/bash /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped ## > >> ERROR with transaction check vs depsolve: >> /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 > >> Then re-tried : >> [root@dhcp201-139 ~]# yum --disablerepo=* --enablerepo=rawhide update >> >> Still no dice. As it still throws -- 'ERROR with transaction check vs >> depsolve:' >> >> Any hints here? > > (Sounds more like a subject for "test" list.) > > Since this unresolved dependency is not listed in the daily rawhide report: > > Can you dig further and find out why you don't have anything that provides > /bin/sh? How to do that? Prior to the upgrade attempt, query your local RPM > database *and* also use repoquery. Then ask repoquery with the rawhide repo > enabled. What do you get? Where did "bash" go? That's what surprised me too. I did try these. 'bash' is right there. ## [root@dhcp201-139 ~]# rpm -qf `which bash` bash-4.2.10-4.fc16.x86_64 ## [root@dhcp201-139 ~]# repoquery -q --whatprovides --alldeps bash --enablerepo=rawhide --disablerepo=* bash-0:4.2.10-5.fc17.x86_64 [root@dhcp201-139 ~]# ## [root@dhcp201-139 ~]# yum repolist enabled Loaded plugins: langpacks, presto, refresh-packagekit repo idrepo name status rawhideFedora - Rawhide - Developmental packages for the next Fedora release 25,139 repolist: 25,139 [root@dhcp201-139 ~]# ## -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum update -- F16-latest => rawhide
On 10/11/2011 11:32 PM, Panu Matilainen wrote: > On 10/11/2011 08:16 PM, Jan Vcelak wrote: >> On Tuesday 11 October 2011 18:22:34, Tomi Leppikangas wrote: >>> Kashyap Chamarthy writes: >>>> Running Transaction Check >>>> ERROR with transaction check vs depsolve: >>>> /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 >>> >>> I have this same problem when trying to upgrade from fedora 15 to rawhide. >>> I noticed that groff-base package have 2 /bin/sh as dependency, is there >>> some whitespace or some other error? >> >> I probably missed that. And I will take a look at it. > > This is a bug in rpm's handling of %pretrans dependencies. I'll try to > get it fixed tomorrow, BUT this also does point out a problem in the > package: > > %pretrans scripts can almost never in real life be /bin/sh scripts, > because on initial installation, at the point where %pretrans scripts > get executed there is no shell! Or anything else for that matter. The > only kind of %pretrans script that always work are ones using the > embedded Lua interpreter, ie '%pretrans -p '. External interpreters > in %pretrans are /supposed/ to work in upgrade scenarios (barring this > bug, duh), but as in practise you can never guarantee a package is only > ever applied as an update on an already running system, %pretrans > scriptlets using /bin/sh or such external interpreter are not usable. Thanks Panu for taking a look. > > - Panu - -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviving packages
> rvm: > https://bugzilla.redhat.com/show_bug.cgi?id=745219 I'm reviewing this. > > In accordance with Fedora policy > (https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package), > I am posting here, and asking for help in re-reviewing these packages. > They are all simple and should be quick reviews, I would appreciate any > help in finishing off these reviews (will trade reviews or favors). > > ~tom > > == > Fedora Project -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum update -- F16-latest => rawhide
On 10/11/2011 08:38 PM, Michael Schwendt wrote: > On Tue, 11 Oct 2011 18:21:03 +0530, KC (Kashyap) wrote: > >> On 10/11/2011 05:29 PM, Michael Schwendt wrote: >>> On Tue, 11 Oct 2011 17:19:22 +0530, KC (Kashyap) wrote: >>> Heya, I'm trying to get rawhide running by yum updating a minimal footprint F16 virtual machine. Only @core package, so no gnome-* nothing else. >>> >>> And no /bin/sh either? It is provided by "bash". >> >> That was the obvious check. I /did/ check that (forgot to mention) >> ## >> [root@dhcp201-139 ~]# ls -al /bin/sh >> lrwxrwxrwx. 1 root root 4 Oct 10 15:20 /bin/sh -> bash >> ## >> [root@dhcp201-139 ~]# file /bin/bash >> /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically >> linked (uses >> shared libs), for GNU/Linux 2.6.32, stripped >> ## > > That check is useless. Only files tracked by the local RPM database and > repository metadata count. > >> That's what surprised me too. I did try these. 'bash' is right there. >> ## >> [root@dhcp201-139 ~]# rpm -qf `which bash` >> bash-4.2.10-4.fc16.x86_64 > > Also a "wrong" test. "rpm -q --whatprovides /bin/sh" would have been > the proper check to find the package(s) that provides /bin/sh _prior_ to > your upgrade attempt. ### [root@dhcp201-139 ~]# rpm -q --whatprovides /bin/sh bash-4.2.10-4.fc16.x86_64 [root@dhcp201-139 ~]# ### > >> ## >> [root@dhcp201-139 ~]# repoquery -q --whatprovides --alldeps bash >> --enablerepo=rawhide >> --disablerepo=* >> bash-0:4.2.10-5.fc17.x86_64 > > What does that tell you? Not much. Instead: > > # repoquery --whatprovides /bin/sh --enablerepo=rawhide --disablerepo=* > bash-0:4.2.10-5.fc17.x86_64 Right, I notice the same too. > > as you want to find out whether anything still provides /bin/sh when > enabling the target repo (one could examine it further in case it isn't > "bash" but an unexpected other package). > Now as /bin/sh is still available, does the full Yum update output say > anything about "bash"? If you mean, just yum update on F16 (w/o enabling rawhide) -- no. If you mean, when target repo(rawhide) is enabled, it /does/ attempt to update 'bash' package. -- . . bashx86_644.2.10-5.fc17 rawhide 978 k -- The error you've seen is not an unresolved > dependency, but something later. With an unresolved dependency, it > would have bailed out even before downloading any packages. You would > have had to add --skip-broken for it to continue. > >> [...] >> Install 6 Packages >> Upgrade 197 Packages >> Remove1 Package >> >> Total size: 108 M >> Is this ok [y/N]: y >> Downloading Packages: >> Running Transaction Check >> ERROR with transaction check vs depsolve: >> /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 > > You somehow lose /bin/sh during the transaction check, which is something > unexpected. Is that reproducible also after cleaning Yum's download cache? Yeah, I was able to reproduce it. I /did/ clear the yum's cache(in fact, removed the var/cache/yum/* ). > What is the full list of packages to be updated? I've uploaded it here: http://kashyapc.fedorapeople.org/full-list-of-rawhide-pkgs-to-be-updated.txt > Is the new "bash" on it, too? Yes. This is the version it tries to update to - bash-4.2.10-5.fc17.x86_64.rpm > Have you looked up the downloaded package below /var/cache/yum > to check it for errors? Would the below suffice ? ### [root@dhcp201-139 packages]# pwd /var/cache/yum/x86_64/16/rawhide/packages [root@dhcp201-139 packages]# rpm -Vp bash-4.2.10-5.fc17.x86_64.rpm [root@dhcp201-139 packages]# ### Thanks for you help so far. -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviving packages
On 10/11/2011 11:59 PM, Kashyap Chamarthy wrote: > >> rvm: >> https://bugzilla.redhat.com/show_bug.cgi?id=745219 > > I'm reviewing this. Done. >> >> In accordance with Fedora policy >> (https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package), >> I am posting here, and asking for help in re-reviewing these packages. >> They are all simple and should be quick reviews, I would appreciate any >> help in finishing off these reviews (will trade reviews or favors). >> >> ~tom >> >> == >> Fedora Project > > -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: serial kernel console vs. systemd
On 05/20/2011 01:19 AM, Josh Stone wrote: > On 05/19/2011 11:57 AM, Lennart Poettering wrote: >> systemd does not redirect kmsg. >> >> We actually are no longer reading console= from the kernel cmdline. We >> now rely entirely on /sys/class/tty/console/active which gives us >> similar information. And we use it only and exclusively to spawn a getty >> on the kernel console after finishing. > > Ok, I was hand-waving because I wasn't sure. > >> Anyway, if kmsg msgs are lost for you this probably happens inside of >> ply or something related, but not systemd. > > Is "ply" part of (or short for) plymouth? I took rhgb out of my command > line, and it's giving me a lot more on serial now. I don't remember > that being necessary before, but I could be mistaken. But I still don't > get anything on a hard crash. Any idea where else I could look to > improve this? To avoid plymouth(as it caused probs earlier while dealing with serial console), I use the below directive on the kernel cmdline. console=tty0 console=ttyS0,115200 rd_NO_PLYMOUTH" > > Thanks, > > Josh -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20140218 changes
On Wed, Feb 19, 2014 at 07:18:12AM +, Fedora Rawhide Report wrote: > Compose started at Tue Feb 18 19:39:04 UTC 2014 > > Broken deps for i386 > -- > [koji] > koji-vm-1.8.0-2.fc20.noarch requires python-virtinst Ping^2? From what I see, here's why this is happening: $ fedpkg clone -B koji $ cd master $ egrep -i 'Requires\: python-virtinst' koji.spec Requires: python-virtinst should be: Requires: virt-install Some more details here: https://bugzilla.redhat.com/show_bug.cgi?id=958499#c4 -- /kashyap -- 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: Server Technical Specification: Agenda and First Draft
On Fri, Feb 28, 2014 at 02:56:52PM +0100, drago01 wrote: > On Fri, Feb 28, 2014 at 2:43 PM, Stephen Gallagher > wrote: [. . .] > SELinux working with it now. > dargo01: I think that statement may be evolving ? > And Docker is moving to systemd-nspawn and away from lxc > but certainly valuable to raise the question on the list, > and see if lennart, dan or dan want to chime in > sgallagh: "Note that even though these security precautions > are taken systemd-nspawn is not suitable for secure container setups. > Many of the security features may be circumvented and are hence > primarily useful to avoid accidental changes to the host system from > the container. The intended use of this program is debugging and > testing as well as building of packages, distributions and software > involved with boot and systems mana > gement." [1] Just to note - recently I did a test to compile libguestfs in a `systemd-nspawn` container. Details here[1] A single `make` job timing to compile everything on a systemd-nspawn: real31m9.792s user17m18.359s sys 13m17.868s For comparison, on the _host_, the same single `make` job timing: real13m41.440s user13m5.816s sys 1m9.911s Notes: - The above was with systemd-208-9.fc20.x86_64. Current systemd in Rawhide (systemd-210-2.fc21) has a lot more improvements - Host and guest are both running Btrfs on Fedora-20 - I'm yet to test with libvirt-lxc tooling [1] https://www.redhat.com/archives/libguestfs/2014-January/msg00290.html -- /kashyap -- 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: Server Technical Specification: Agenda and First Draft
On Sun, Mar 02, 2014 at 04:05:27PM +, Richard W.M. Jones wrote: > On Sat, Mar 01, 2014 at 02:58:41PM +0530, Kashyap Chamarthy wrote: [. . .] > > > > A single `make` job timing to compile everything on a systemd-nspawn: > > > > real31m9.792s > > user17m18.359s > > sys 13m17.868s > > > > For comparison, on the _host_, the same single `make` job timing: > > > > real13m41.440s > > user13m5.816s > > sys 1m9.911s > > These results don't make much sense to me. I would expect make to > take a similar time on both. Hmm, I didn't start out with comparisions as I was testing it for the first time. I'll conduct another test (more carefully, this time) with newest systemd from Rawhide and see how it fares. (Also, will try with a libvirt-lxc and report how it goes.) > > Do you have a proxy/cache that could be caching the RPMs that > yumdownloader fetches during the build? I don't have a proxy/cache (should really make one!). However the Fedora mirror is on the same network of the machine where I the test on. > > Did you do the second build in the same directory as the first build? No, it's done in my home dir -- ~/kashyapc/src/libguestfs. First one is in /src/test-container > 'make clean' intentionally doesn't clean up some things like the > appliance and test images which require lengthy rebuilds. You have to > use 'make maintainer-clean' or 'make distclean' instead. > > libguestfs make (and especially 'make check') is a good stress-test, > but it's too complicated and irreproducible to be a good benchmark. Yeah, trying to report benchmarks is always tricky. Answering drago01's questions from the other email: - Order: first I ran the compile test via nspawn container; next, run the same test on the in my home dir (on the host) - No, I didn't reboot in between - Haven't cleared caches (I presume you meant to free the pagecache -- $ echo 3 > /proc/sys/vm/drop_caches) -- /kashyap -- 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: Attempting to contact three unresponsive maintainers
On Fri, Mar 28, 2014 at 10:11:47AM -0700, Toshio Kuratomi wrote: > Greetings, we've been told that the email addresses for three package > maintainers are no longer valid. I'm starting the unresponsive maintainer > policy to find out if they are still interested in maintaining their > packages (and if so, have them update their email addresses in FAS). If > they're not interested in maintaining or we can't locate them I'll have > FESCo orphan the packages so that others can take them over. > > If you have a way to contact any of these maintainers, please let them know > that we'd appreciate knowing what to do with their packages. Thanks! > > Maintainers: > * awnuk -- former email address aw...@redhat.com He doesn't work for Red Hat anymore. I CC'ed Ade Lee who leads upstream Dogtag work, he might suggest someone who is willing to take up the maintenance. > - comaintainer of dogtag-pki, dogtag-pki-theme, pki-console, pki-core, > pki-ra, and pki-tps > -- /kashyap -- 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: Why does so much virt stuff depend on glusterfs?
On 07/23/2013 10:27 PM, Dave Jones wrote: > On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote: > > So this thread is complaining about.. > > > > Removing: > > > glusterfs x86_64 3.4.0-2.fc19 > @updates-testing 4.7 M > > > Removing for dependencies: > > > glusterfs-api x86_64 3.4.0-2.fc19 > @updates-testing 88 k > > > glusterfs-fuse x86_64 3.4.0-2.fc19 > @updates-testing 233 k > > < 5M of deps, meanwhile.. > > > > qemu-system-alpha x86_64 2:1.4.2-4.fc19 > @updates-testing 4.1 M > > > qemu-system-arm x86_64 2:1.4.2-4.fc19 > @updates-testing 5.2 M > > > qemu-system-crisx86_64 2:1.4.2-4.fc19 > @updates-testing 2.8 M > > > qemu-system-lm32x86_64 2:1.4.2-4.fc19 > @updates-testing 2.8 M > > > qemu-system-m68kx86_64 2:1.4.2-4.fc19 > @updates-testing 3.8 M > > > qemu-system-microblaze x86_64 2:1.4.2-4.fc19 > @updates-testing 5.6 M > > > qemu-system-mipsx86_64 2:1.4.2-4.fc19 > @updates-testing 21 M > > > qemu-system-or32x86_64 2:1.4.2-4.fc19 > @updates-testing 2.7 M > > > qemu-system-ppc x86_64 2:1.4.2-4.fc19 > @updates-testing 18 M > > > qemu-system-s390x x86_64 2:1.4.2-4.fc19 > @updates-testing 3.1 M > > > qemu-system-sh4 x86_64 2:1.4.2-4.fc19 > @updates-testing 7.5 M > > > qemu-system-sparc x86_64 2:1.4.2-4.fc19 > @updates-testing 7.3 M > > > qemu-system-unicore32 x86_64 2:1.4.2-4.fc19 > @updates-testing 2.7 M > > > qemu-system-xtensa x86_64 2:1.4.2-4.fc19 > @updates-testing 5.6 M > > Do we really *need* all those ? (And why are mips & ppc so much bigger ?) To get a minimal working KVM based virt, I used to run: $ yum install libvirt-daemon-kvm libvirt-daemon-config-network \ libvirt-daemon-config-nwfilter -y $ yum install virt-install -y # This is what is pulling in all the other arch qemu deps $ yum install libguestfs libguestfs-tools libguestfs-tools-c -y -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFC] Easiest making kernel rpms from upstream git
On 08/28/2013 07:23 PM, Igor Gnatenko wrote: > Today I've wrote article w/ many notes about bisecting kernel [0], but > I've used make bzImage, make install and the same commands bypassing RPM > and I have IMHO good idea to write utility, that will be build rpm w/o/ > Fedora patches, changelogs, etc. simple rpms w/ one command. > > We will use "utilityname `git rev-parse HEAD` f19" instead of "make > bzImage && make modules" and "yum install ./rpms/*.rpm" instead of "make > install && make modules_install". > > This software should increase the effectiveness, simplify the build test > kernels, simplify to work w/ installed kernels (e.g. remove). Also we > can easy provide rpms to bugreport for testing regressions, etc. Incidentally, just today, I was building upstream kernels manually (for testing some KVM specific things). I don't build Kernels often. After some trial and error, I ended up with this sequence: $ make -j6 && make bzImage && make modules $ make modules_install && make install Couple of times Dracut failed to generate correct initramfs, resulting in froze. With a hint from Haralad Hoyer on IRC, I generated the initramfs manually (usually, using the host initrd should be sufficient): $ dracut /boot/initramfs-3.11.0-rc1+.img 3.11.0-rc1+ $ depmod -a > > I see alike software at bubuntu wiki [1]. > > Would anyone besides me find this useful enough for me to keep working > on it? Sure, I can certainly be a user here :-) . Note to self: Still have to debug/bisect an offending Kernel commit which is causing some KVM unit test failures. > > [0]https://fedoraproject.org/wiki/User:Ignatenkobrain/Kernel/Bisection > [1]https://wiki.ubuntu.com/Kernel/KernelBisection#Build_Upstream_Test_Kernel > -- /kashyap -- 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: Flock proposals now open for community voting
On 06/03/2013 10:06 PM, Tom Callaway wrote: > Thanks to the Fedora Community for submitting 125 awesome talks, > hackfests, sprints and workshops for Flock, our new contributor conference! > > We've taken those submissions and put them in the Fedora Elections web > application, and now, it is time for you to give us your feedback. These > proposals have been submitted by the Fedora community and we want the > Fedora community to tell us what _you_ want to see! Even if you cannot > attend Flock in person, these sessions will be streamed and recorded, so > your vote is appreciated! > > If you have a Fedora Account (they are free to create), and have agreed > to the Fedora Project Contributor Agreement (FPCA), you can vote for the > 125 submissions here: Tom/Anyone: Is it purposeful to not have presenter's name next to each talk's Abstract ? Or is it a limitation of the talk proposal system ? Or am I just terribly blind ? -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Flock proposals now open for community voting
> > The latter :-) Thanks Bill, Rahul. Sorry for this noise. Note to self: *Read* the goddamn email completely (especially at 01:00 AM) before hitting the send! -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Flock proposals now open for community voting
On 06/04/2013 08:37 PM, Matthew Garrett wrote: > On Tue, Jun 04, 2013 at 10:22:50AM -0400, seth vidal wrote: > >> I disagree - this lets people judge proposed talks/sessions on what is >> written. > > I don't go to presentations because of the quality of the abstract. I go > to presentations based on whether or not I believe the speaker is > competent in the field they're talking about and able to communicate > that competence. It's vital information for making a realistic judgement > of whether a proposal should be in the final program or not. Indeed. Abstract can be polished to hell and back to bring it to a certain "quality". But if I'm attending a talk, I'd rather look up the presenter. If it's a young/new gun, and topic piques my interest, I might go anyway :) But these are personal preferences and classic bike-shedding topics. So, I'll stop my monologue here :) -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: review swap?
On 06/13/2013 01:59 PM, Alec Leamas wrote: > Anyone interested in swapping reviews with my two pending requests? > > - 972943 lpf I'm waiting for some build to complete, meantime, I can try this one :) > - 956134 mnmlicons-fonts > > Both looks in my eyes simple. All offers welcome! > > --alec > -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[RFC] Python_Eggs packaging guideline clarification draft
The topic of Python eggs came up during the discussion of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1178754 -- [abrt] python-gertty: script.py:46:__init__:CommandError: Path doesn't exist: '/usr/lib/python2.7/site-packages/gertty/alembic'. Please use the 'init' command to create a new scripts folder. After a bit of back and forth on #fedora-python, Toshio Kuratomi suggested a clarification change. Here's the clarification draft to that effect (thanks Toshio for the review): - Proposed: https://fedoraproject.org/wiki/User:Kashyapc/Python_Eggs - Original: https://fedoraproject.org/wiki/Packaging:Python_Eggs FPC ticket: https://fedorahosted.org/fpc/ticket/488 Changes --- 1. Replaced the term 'eggs' with 'egg metadata' in the whole wiki, while not messing up the URLs to this[1] on both occurances. 2. In section '1.1 Why egg metadata', changed the phrase "Allowing end users to install eggs not made from rpms or install eggs into their home directories." to "Allowing end users to install egg packages not made from rpms or install egg packages into their home directories." 3. In section '1.2 When to Provide egg metadata' changed the phrase "we need to be sure to include the egg files" to "we need to be sure to include the egg metadata" 4. Changed the section 1.3 tittle from "Upstream egg metadata" to "Upstream egg package" 5. In section 1.3, change the phrase: "Do not distribute egg metadata from upstream" to "Do not distribute egg packages from upstream." -- /kashyap -- 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: [RFC] Python_Eggs packaging guideline clarification draft
On Wed, Jan 07, 2015 at 02:35:52AM -0500, Bohuslav Kabrda wrote: > > > > Changes > > --- > > > > 1. Replaced the term 'eggs' with 'egg metadata' in the whole wiki, while > >not messing up the URLs to this[1] on both occurances. > > > > 2. In section '1.1 Why egg metadata', changed the phrase "Allowing end > >users to install eggs not made from rpms or install eggs into their > >home directories." to "Allowing end users to install egg packages not > >made from rpms or install egg packages into their home directories." > > > > 3. In section '1.2 When to Provide egg metadata' changed the phrase "we > >need to be sure to include the egg files" to "we need to be sure to > >include the egg metadata" > > > > 4. Changed the section 1.3 tittle from "Upstream egg metadata" to > >"Upstream egg package" > > > > 5. In section 1.3, change the phrase: "Do not distribute egg metadata > >from upstream" to "Do not distribute egg packages from upstream." > > All the changes LGTM, thanks a lot for doing this! Thanks for the review, Bohuslav. Seems like the FPC ticket is already picked up, thanks Tibbs. -- /kashyap -- 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: official fedora image for docker available
On 01/03/2014 10:46 PM, Lokesh Mandvekar wrote: > The official (unprefixed) fedora image for docker is now available here: > https://index.docker.io/_/fedora/ > > It has fedora 20 (via tags 20, heisenbug and latest) and rawhide. When cross-posting to lists like fedora-devel (where a broad range of topics get discussed), it's useful to add some more *context* on how to use/or a URL to usage for people who don't interact with Docker on a daily basis. The URL you posted doesn't have an actual image! It's merely contains a command to pull the image once you have Docker installed, enabled the service, etc. $ sudo yum install docker-io $ sudo systemctl enable docker.service $ sudo systemctl start docker.serivce $ sudo docker pull fedora (And, as others noted on the list - it's useful to double-check with rel-eng before announcing anything as 'official') /kashyap -- 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: "a stop job is running for User Manager for 0"
On Thu, Feb 06, 2014 at 02:43:07PM -0500, Paul Wouters wrote: > > I'm using a minimal netinstall version of fedora20 for testing using > KVM. We very often cycle these machines (once per test, we run hundreds > of tests) I run minimal installs all the time, with either a script like that[1] or with 'virt-builder' invoked as: $ virt-builder fedora-20 --format qcow2 --size 10G $ virt-install --name f20vm1 --ram 2048 --disk \ path=/export/images/fedora-20.img --import I'm not seeing any such issues you describe, but, of course, the above is not a netinstall, so something could be different in your environment. > > Regularly, we get tests failing because the VM does not boot within 60 > seconds, and seems to hang at: > > "a stop job is running for User Manager for 0" > > The machine is still in single user mode, so I cannot get any more > information out of it. Not even `journalctl` to display boot messages with error priority? $ $ journalctl -b $ journalctl -b -p err > The message is rather useless, because it does > not tell me anything about the problem. Which job is still running? What > is it waiting for? What's a User Manager? Who is "0"? > > I'm not even sure at what component we are looking for to report a bug :( > > Does anyone have more information for me? A couple of related bugs[2][3]. The RH bugzilla URL below has some journalctl diagnostics information. [1] https://github.com/kashyapc/virt-scripts/blob/master/create-guest-qcow2.bash [2] https://bugs.freedesktop.org/show_bug.cgi?id=70593 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1023820 -- /kashyap -- 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: "a stop job is running for User Manager for 0"
On Sun, Feb 09, 2014 at 12:35:20PM +0530, Kashyap Chamarthy wrote: [. . .] > > The message is rather useless, because it does > > not tell me anything about the problem. Which job is still running? What > > is it waiting for? What's a User Manager? Who is "0"? > > > > I'm not even sure at what component we are looking for to report a bug :( > > > > Does anyone have more information for me? > > A couple of related bugs[2][3]. The RH bugzilla URL below has some > journalctl diagnostics information. > > > [1] > https://github.com/kashyapc/virt-scripts/blob/master/create-guest-qcow2.bash > [2] https://bugs.freedesktop.org/show_bug.cgi?id=70593 > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1023820 I replied without seeing the rest of the thread. I see that you found a workaround. -- /kashyap -- 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: rawhide report: 20140208 changes
On Sat, Feb 08, 2014 at 06:55:18PM +, Fedora Rawhide Report wrote:
[. . .]
>
> [koji]
> koji-vm-1.8.0-2.fc20.noarch requires python-virtinst
There's an F19 bug here for this:
https://bugzilla.redhat.com/show_bug.cgi?id=958499
koji-vm should not be using python-virtinst code
From a quick inspection, the Rawhide koji-vm SPEC still has:
Requires: python-virtinst
which should be:
Requires: virt-install
because:
$ koji latest-build rawhide python-virtinst | awk '{print $1}'
Build
$ echo $?
0
And, see the above bug.
--
/kashyap
--
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: In A World Where...TCs don't exist?
On Sat, Jan 30, 2016 at 09:11:49PM +0100, Dennis Gilmore wrote: > Already added to our next grooming meeting. Nice. Without realizing this discussion already happened here, I asked Dennis the same question as Rich, about the status of the its (virt-builder's) metadata distribution as part of Fedora composes, earlier this afternoon during his Rel Eng talk at DevConf in Brno. Thanks for the talk, Dennis! > On January 29, 2016 7:56:05 PM GMT+01:00, Matthew Miller > wrote: > >On Fri, Jan 29, 2016 at 10:07:14AM -0600, Dennis Gilmore wrote: > >> > > > https://fedorahosted.org/rel-eng/ticket/5805 > >[...] > >> We have none of that info and its not yet on our radar. > >> https://fedoraproject.org/wiki/ReleaseEngineering/PriorityPipeline is > >> the list of things we have coming up. I think there are some not > >> documented as well as they should be. > > > >I think this request just kind of fell through and didn't get included > >in the new prioritization process. Let's get it added in as something > >for _sometime_ in the future, even if it doesn't bump current > >priorities. -- /kashyap -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Review swap: virt-v2v
- Original Message - > > * https://bugzilla.redhat.com/show_bug.cgi?id=1774713 > Review Request: virt-v2v - Convert a virtual machine to run on KVM > > This is actually more of a package split. This program was part of > libguestfs, but has been split out into a separate upstream project: > > https://github.com/libguestfs/libguestfs/commit/85c99edec19ac7afb38fa6003e35f51db143922c > https://github.com/libguestfs/virt-v2v > > and removed from the Fedora libguestfs package: > > https://src.fedoraproject.org/rpms/libguestfs/c/85c51621ab836847051f59cc4c943025b4bd8f89?branch=master (Happened to notice this the first thing after I opened 'fedora-devel' in a while.) I'll take it; it's been a while since I reviewed a Fedora package, would be a good, quick refresher. [...] -- /kashyap ___ 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: Konflux: What is the right time?
On Sat, Mar 08, 2025 at 07:50:49AM +, Richard W.M. Jones wrote: > On Fri, Mar 07, 2025 at 12:56:21PM -0800, Brendan Conoboy wrote: > > > > This doesn't really help with the "what". I work at Red Hat and still > have no idea what Konflux actually is. [...] > > ”. In his talk he related some of the details about the interim rpm > > approach, which injects builds into the koji after a build is > > complete. This seems weird, but it makes sense: When your goal is to > > eventually replace the full pipeline, but it’s going to take a long > > time, you have to write some throw-away code that bridges new to > > old. > > I didn't watch his talk, but this all sounds very vague. And that the > fact that it's "container first" and an internal project first is > worrying too. How does it build containers without starting with > RPMs? Where do those RPMs come from? I was present at the talk, here[1] are the slides. There's a Workflow diagram on slide-10. No direct answer, but allow me to quote Mike McLean's slide-11, on building RPMs (with some changes to Mock): --- # we want to build this package srpm=your-package.src.rpm # we'll create a local repository with pre-fetched RPMs/bootstrap repo=/tmp/local-repo # resolve build deps for the given SRPM, in this case for Fedora Rawhide mock --calculate-build-dependencies -r fedora-rawhide-x86_64 "$srpm" # find the lockfile in Mock's resultdir lockfile=/var/lib/mock/fedora-rawhide-x86_64/result/buildroot_lock.json # create a local RPM repository (+ download bootstrap image) mock-hermetic-repo --lockfile "$lockfile" --output-repo "$repo" # perform the hermetic build! mock --hermetic-build "$lockfile" "$repo" "$srpm" --- > TL;DR, I don't know what this is. I asked a question about some of the main motivations behind Konflux: Is it the ability to build containers "natively? Or is it about "SBOM" (software bill of materials) and "hermetic builds" that provide an attestation report? Something else? I didn't get a direct answer to this, but the presenter (Mike McLean) said he was there to share how _he_ is using Konflux to build RPMs. Fair enough, but my question remains: did the Konflux project consider the option of investing this effort into Koji to produce the artifacts they need? Maybe it was already considered and ruled out due to valid reasons. If they're documented somewhere, I'd be glad to educate myself. If not, Konflux project folks: please consider documenting. It'll also answer questions the broader community might have. [...] [1] https://mikem.fedorapeople.org/Talks/connect-2025-rpms-in-konflux/#11 -- /kashyap -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Konflux: What is the right time?
On Tue, Mar 11, 2025 at 10:40:02AM +0100, Kashyap Chamarthy wrote: (I sent my email before pulling down 'fedora-devel'; I saw there were other responses that answer one of my questions.) > > TL;DR, I don't know what this is. > > I asked a question about some of the main motivations behind Konflux: Is > it the ability to build containers "natively? Or is it about "SBOM" > (software bill of materials) and "hermetic builds" that provide an > attestation report? Something else? I didn't get a direct answer to > this, but the presenter (Mike McLean) said he was there to share how > _he_ is using Konflux to build RPMs. > > Fair enough, but my question remains: did the Konflux project consider > the option of investing this effort into Koji to produce the artifacts > they need? Maybe it was already considered and ruled out due to valid > reasons. If they're documented somewhere, I'd be glad to educate > myself. If not, Konflux project folks: please consider documenting. > It'll also answer questions the broader community might have. Okay, Stephen Smoogen and Kevin Fenzi answer one of my main questoins: - "It isn't a koji replacement, it is a Fedora Build System replacement" (Stephen) - "The idea isn't to just swap konflux in for koji and call it a day, but rather to use konflux as a build pipeline [src.fp.o, sigul, `bodhi`, et al]" (Kevin) [...] -- /kashyap -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: Allow all packagers to push empty commits to any package
On Thu, Feb 20, 2025 at 01:17:02PM +0100, Miro Hrončok wrote: > Hello. > > With the recent discussions about provenpackagers in Fedora, I recently got > an idea. > > One of the common needs for provenpackagers is to simply "bump and rebuild" > a set of dependencies. I guess this "common need" is an example that be grouped under the heading of "packagers should be considered as custodians" (or "guardians"), instead of "owners". It was described in the thread[1] that you allude to. > All packagers are already able to build anything (except a very specific and > small set of specially-signed packages). However, to bump the package, they > need commit rights. For that reason, provenpackager rights are often > required. > > With the wide adoption of %autorelease, such bump commits are empty, which > should be easy to verify. > > What if we allowed all packagers to push empty commit to any package? That > should eliminate *some* need for provenpackager access. We would also > communicate in our policies that such bumps do not require prior agreement > with the maintainers to avoid confusion about "what are we allowed to do". FWIW, sounds reasonable to me, assuming it's limited to Rawhide only for now. If that works well, then probably it can be extended to stable branches, based on the feedback from more active packagers. (I don't pretend to understand all the implications here :)) [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/URVJB22ITA7RPCMVOUBTQ6SB5D6JI4JX/ -- /kashyap -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: AI-generated content in Fedora packages: do we have rules?
On Fri, Jul 18, 2025 at 12:56:55PM +0200, Florian Weimer wrote: > * Daniel P. Berrangé: [...] > You don't know that if you are reviewing an unsolicited contribution, or > a contribution not directly targeted at Fedora. You don't set the rules > for those. > > > IMHO that is materially different, because the former is only a problem > > for the small subset of untrustworthy developers who deliberately ignore > > their obligations, while the latter problem can unwittingly affect any > > developer who uses the tools no matter how diligen tthey are. > > I disagree. Today, we only have approval of licenses, not approval of > content. Maintainers are not required to check that content they import > from upstream or other upstream-associated sources (such as a patch > posted on an upstream mailing list) is actually covered by the declared > license or the license implied by association with the specific upstream > project. As this discussion shows, there are still many open questions here. One of the guidelines I heard for evaluating LLM-generated code is, asking yourself: "is it misleading?" I know it's a loaded question that needs unpacking. Take the case where the code is entirely generated by an LLM. Now, putting the human who wrote the prompt as an "author" is ethically wrong and misleading. Same goes for using some kind of restrictive license on that code — on what basis should this be decided, if any at all? (I'm not asking for an answer here.) Some "common sense guidelines" that Fedora could explicitly spell out: - Do your best to not mix up man and machine. If you're not sure, delcare precisely what you did when submitting code authored by LLMs or LRMs. - Make sure you understand the LLM-generated code you're submitting. Meaning, don't put the "burden of untangling" what is human and machine from what you submitted on reviewers / maintainers. - As Richard Fontana noted in this thread, consistently "mark" the AI content using explicit tags such as: "Assisted-by:" or "Generated-by:", or "Co-authored-by:", etc The human should go further and spell out what is human-authored vs. machine-authored, or what was the extent of your own editing or modification. Plainly and clearly explain the truth in Git commit messages, source file comments, etc. -- Kashyap Chamarthy / Red Hat / RISC-V and Fedora -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 42 RISC-V (non-official) images are available!
Hi, folks! Fedora 42 images for the RISC-V *alternative* architecture are now available[1]! Please note that RISC-V not yet a Fedora primary architecture. These *non-official* images are brought to you by the Fedora RISC-V Community. This release includes server, cloud, and container images. Among the server images, in addition to the "host generic" option, there are also two hardware-specific images: one for the SiFive "HiFive Premier P550" and another for Milk-V "Megrez". A list of supported and experimental hardware is available here[2]. Installation instructions for StarFive VisionFive2 are available here[3] and for HiFive Premier P550 here[4]. The "Fedora-Server-Host-Generic" and "Fedora-Cloud-Base-Generic" images aren't tied to specific hardware, so you can test them with emulation software such as QEMU. If you want to give them a spin, here[5] are the instructions. Any issues, hit us up on the Fedora RISC-V Matrix channel[6]. [1] https://dl.fedoraproject.org/pub/alt/risc-v/release/42/ [2] https://fedoraproject.org/wiki/Architectures/RISC-V/Hardware [3] https://fedoraproject.org/wiki/Architectures/RISC-V/StarFive/VisionFive2 [4] https://fedoraproject.org/wiki/Architectures/RISC-V/SiFive/HiFivePremierP550 [5] https://fedoraproject.org/wiki/Architectures/RISC-V/QEMU [6] https://chat.fedoraproject.org/#/room/#riscv:fedoraproject.org Regards, Fedora RISC-V Community -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
