RE: [Fedora-livecd-list] SRPMS for installed RPMs?
by Jeroen van Meeuwen
Hey, this is done already. Downloading packages includes downloading the corresponding SRPMs, even for Live Media.
/me, from his cell
-----Oorspronkelijk bericht -----
Van: "Jonathan Steffan" <jonathansteffan(a)gmail.com>
Aan: fedora-livecd-list(a)redhat.com
Verzonden: 07-08-13 22:25
Onderwerp: Re: [Fedora-livecd-list] SRPMS for installed RPMs?
On Mon, 2007-08-13 at 22:11 -0500, Matt Domsch wrote:
> I want to be sure, for license compliance, that all the binary bits on
> the final LiveCD have corresponding source code available.
>
> One of the "features" I'd like to see something in the stack of
> livecd-tools produce is a CD/DVD/whatever of the SRPMS that match the
> RPMs that go into the LiveCD. Smooge and I have both done this
> ourselves, with varying degrees of ease, essentially querying all the
> installed RPMs on the LiveCD after-the-fact and generating the list,
> then grabbing the files etc. All very manual. I expect there's a
> better way, and I'm even open to helping code it, but am looking for
> direction from you - those who know the tools best...
We can just use the same concept that pungi uses. The revisor team is
actually working on this and when we have progress we'll let the list
know. If anyone wants to just get it done, please do.
def getSRPMList(self):
"""Cycle through the list of package objects and
find the sourcerpm for them. Requires yum still
configured and a list of package objects"""
for po in self.polist:
srpm = po.sourcerpm.split('.src.rpm')[0]
if not srpm in self.srpmlist:
self.srpmlist.append(srpm)
Start reading at line 327
of /usr/lib/python2.5/site-packages/pypungi/gather.py:
def downloadSRPMs(self):
"""Cycle through the list of srpms and
find the package objects for them, Then download them."""
[...]
Jonathan Steffan
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
16 years, 8 months
Can't boot LiveCD Boot on MS Virtual Server 2005 R2
by Jon Steer
My LiveCD boot is hanging when booting from MS Virtual Server 2005 R2.
F6 based LiveCD's worked fine.
It hangs at
Uncompressing Linux.. Ok, booting the kernel.
Since the box is running on a Dell Dual Core box, I tried all the
maxcpu suggestions but no joy.
Any ideas? Any ideas on what I can enable to get some tracing?
thanks,
jon
--
"Whereever you go, there you are"
16 years, 8 months
RFC- mayflower flexibility enhancements
by Douglas McClendon
I have a few changes I'd like to request to mayflower. I'd like to get
some feedback before actually laying down the effort of producing patches.
#1 - mayflower.conf - add PROGRAMS and FILES
I'd like it if mayflower, in addition to supporting MODULES+= lines,
would also support PROGRAMS+= and FILES+=
PROGRAMS+= would be used for example, in my prior persistence patch, to
add things like ntfsmount.
FILES+= would differ from PROGRAMS, in that the auto shared library
dependency check would not apply to them. Maybe that doesn't matter,
and you could just have FILES.
#2 - support user specified mayflower.conf location
(i.e. not just /etc/mayflower.conf)
#3 - optional program, sort of like existing shell cmdline arg
Have a cmdline argument of program= and eprogram= which would cause the
specified program to be executed. program= would happen right after the
current shell, and eprogram would happen right after the current eshell.
You would of course supply your own custom program via #1 above.
Now, you are no doubt asking, what would this be used for...
Answers:
1) support SELinux enabled livecd creation from an SELinux disabled
build system.
2) support building of anaconda rpm as a non root user
3) support livecd-creator as a non root user
Now you are no doubt asking, how do #1 #2 & #3 get you 1) 2) and 3)?
The answer is by implementing the qmkfs program I alluded to a long time
ago on fedora-devel, and it's more general incarnation, qrr (qemu root run)
The idea is this- qrr is a script. qrr reads it's input, a config file,
describing a program and some data. qrr then invokes mayflower (as a
user, not root, with #2) to generate an initramfs, that is basically the
same as the livecd initramfs, but with extra programs, specified by the
config file, and added with #1. Then, qemu is invoked with #3, somewhat
like this-
mkdir ./my_input_output_dir
cp -av <user supplied input data> ./my_input_output_dir
qemu-img create scratch.img 10G
qemu -kernel /boot/vmlinuz-$(uname -r) \
-initrd ./my_mayflower_generated_initrd.img \
-append "program=/my_custom_qrr_program" \
-hda ./scratch.img \
-hdb fat:rw:./my_input_output_dir
Thus, the mayflower initramfs boots, runs the user supplied
my_custom_qrr_program, which mounts the my_input_output_dir, and
proceeds to process it with root privs (i.e. it can do loopback mounts,
selinux relabeling, etc...), and then leaves its output (e.g. a
filesystem image) in my_input_output_dir.
I think that the changes involved with #1 #2 and #3 are fairly minor,
elegant, and safe. Actually implementing 1) and 2) are a bit tricky.
3) is probably a lot tricky, but arguably worth the effort.
Mainly I want this feature (qrr) for my own currently private project,
though I would definitely go ahead and implement 1) as part of the
patchset to be submitted for merging, which I think is justification
enough for #1 #2 and #3.
In general, the ability to use mayflower to construct arbitrarily useful
custom purpose initramfs-s, seems quite useful. I imagine that when
people really start to think about this, and what it allows, they will
come up with many uses that I would probably never imagine.
Personally I am hoping for a koji/pungi/livecd-creator/revisor that does
not require root privileges at all. It seems to me like there should be
no reason why a non-root user cannot take the fedora cvs/git trees, and
output (customized) F9 media sets.
I realize this may sound like a lot of stuff, but please focus on how
small and safe the patches to support #1 #2 and #3 really are.
Also, I have basically done this somewhat manually. (tweaked mayflower,
generated initramfs as user, booted qemu to get arbitrary program to run)
questions/comments/criticisms?
-dmc
16 years, 8 months
RFC- improving livecd installer efficiency
by Douglas McClendon
Question: Does the current livecd installer inefficiently write lots of 0's to
the destination drive that it doesn't need to?
I think it might. The os.img on the F7 livecd is a 4G sparse file with about
2.3G of data. Anaconda's livecdcopy backend uses python's os.read/write. I
would guess that that means that 4G of data is getting written, when
theoretically only 2.3G needs to.
The solution that comes to mind is this-
in livecd-tools, create the os.img as a 7G (or 700G??) sparse file. Basically
just way big. Then take care to make the ext3fs be the exact correct size for
the data (i.e. 2.3G). Then, in the initramfs, just after mounting it (after
snapshotting it), do a resize2fs to 7G (or 700G).
Then when anaconda does the copy, only copy the first 2.3G of the sparse file.
It is however late in the 'day' for me, so maybe someone can chime in with
confirmation or refutation of my logic here.
-dmc
16 years, 8 months
Commits to the list?
by Jeremy Katz
Okay, I've finally gotten the git commit mail script to work with the
weird git setup on git.fedoraproject.org. Any objections to send the
commit mails to the list?
Jeremy
16 years, 8 months
[PATCH 3/6] Setting the yumcache
by Jeroen van Meeuwen
A patch to change the location of the yum cache directory.
This enables existing yum cache to be used, which in our case is
especially useful because that cache is populated already. Most
importantly, livecd-creator doesn't bind mount the yum cache directory.
Kind regards,
Jeroen van Meeuwen
-kanarip
16 years, 8 months
[PATCH 1/6] Set the build directory
by Jeroen van Meeuwen
A patch to enable setting the build directory.
This adds more flexibility for those who don't have as much space in
/var/tmp.
Kind regards,
Jeroen van Meeuwen
-kanarip
16 years, 8 months
