When running pungi on a F17 system with all updates applied, it seems
to work fine when I only use the F17 release repo in the config file, but
it creates uninstallable media when I also include the F17 updates repo.
Then, when booting the DVD, it times out after a long time when spawning
the shell on tty2 and after selecting the keyboard it runs into a Python
Are these known problems and what can I do about it? My main goal is
to create media to install an up-to-date F17 from (only) DVD.
Otherwise I'll file a bug with all details.
I posted this earlier today to the buildsys list, but I think this
devel list is a better place to get more feedback.
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
Fedora infrastructure has been looking at moving from gitweb-caching to
cgit for git.fedorahosted.org and pkgs.fedoraproject.org. Some reasons:
gitweb-caching upstream is not very alive.
gitweb-caching needs manual clearing of it's cache from time to time.
gitweb-caching seems to run into security issues, and due to inactive
upstream it's difficult to fix.
gitweb-caching cannot handle the number of repos in
pkgs.fedoraproject.org and doesn't display a useful top page.
gitweb-caching seems to leave lingering old git-daemon processes
cgit cleans up after itself.
cgit can display the pkgs.fedoraproject.org repo collection (all be it
if it's not cached currently it takes a while the first hit and splits
pkgs into 248 pages).
cgit seems to have a somewhat active upstream.
cgit is faster.
cgit displays UTF8, where gitweb-caching often doesn't.
We have already pushed cgit live for folks to look at:
We don't want to carry a ton of redirects/rewrites forever, so we were
planning on just adding a few to go to the project if we can tell what
that was/is and redirect the rest to the top level to use the search
We would like to make this change on 2012-07-30, unless there's some
show stopper found before then.
In the mean time, if everyone could:
- Move any scripts or processes you have that use a gitweb-caching url
to using a cgit one.
- Look over the interface(s) above and let us know (via a
infrastructure ticket or #fedora-admin) if you run into a issue with
Let us know if you have any other issues or concerns.
No rush on this I *just* posted it and sadly I don't have a lot of
time to swap reviews. I thought I would point out that I had posted a
review for php-pecl-cairo if anyone is interested in having it in fedora
so they could review it.
Nathanael d. Noblet
Good day all,
This weeks Fedora ARM status meeting will take place today (Wednesday July 18th) in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):
Current items on the agenda:
1) Builders on F17 - status update
2) F18 Mass rebuild
3) Raspberry Pi Remix update
4) Your topic here
If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting.
I have a package which builds fine on my host, as I have my required rpm's
installed. How do I install my dependencies in koji so the package
For example, I need zlib-devel to be installed and lapack-devel
Yesterday I was working on migrating the legacy sysv scripts for
mailscanner to native systemd when I came across this wiki page .
Does anyone know what the current status of this is in the project?
It would be good to get an feed back on certain things with the
migration of it from those that actually use it.
As things stand now on the migration part is that.
I have created MailScanner.service which from the looks of it obsoletes
In addition to that I created sendmail-in.service and
sendmail-out.service sm-client-ms.service which is starting sendmail and
sm-client with the parameters found in the legacy sysv init file and was
looking at postfix and exim when I stopped since to me this felt as the
wrong approach migrating this.
Now the problem here is that I feel we should always use the existing
unit files for those daemons and if application wants to have them
started up differently the administrator should just follow  or that
the package installs a new unit file based on  into
/etc/systemd/system with those parameters instead of creating new unit
Thoughts comments appreciated