the need of "Offline Updates"
by Reindl Harald
the whole discussion abiut offline updates and why yum is not so good
for dist-upgrades is from the wrong point of view, most of the problems
are only existing because with each release working things are mangeled
actual example:
https://bugzilla.redhat.com/show_bug.cgi?id=907749
https://bugzilla.redhat.com/show_bug.cgi?id=887763#c20
bothing bad would happen if the package would not touch
/etc/mtab
________________________________________
the same for updates of services:
nothing would happen on a webserver with httpd if it would not be
restarted at package-update which goes wrong if you are using PHP
and packages of the dep-tree are not yet all updated which fails
PHP to load, without the hardcoded restart httpd would happily
continue to run with the old php-package from memory
so all the problems which are statet against yum-upgrades
are introdouced about the last 5-6 years and were not
existing before
what currently happens is that more and more HARD-WIRED
cross-dependencies are introduced, more and more magic
ist introduced and at the end of the road we will be on
the windows way "you touched anything on the system and
so please reboot now"
11 years, 3 months
Orphaning em8300 related stuff
by Felix Kaechele
Hi there,
I'm orphaning
em8300 in Fedora and
em8300-kmod in RPMFusion
because I no longer own the hardware to use it.
Also, it has seen little love from upstream.
Feel free to take it.
Regards,
Felix
11 years, 3 months
Re: Self Introduction
by Jeremy White
On 02/13/2013 10:03 AM, Jared Smith wrote:
>
> On Wed, Feb 13, 2013 at 10:26 AM, Jeremy White <jwhite(a)codeweavers.com> wrote:
>> > I am writing to introduce myself. I have submitted a package review
>> > request for the spice-html5 javascript SPICE client here:
>> > https://bugzilla.redhat.com/show_bug.cgi?id=910793
> I'm not a sponsor (yet?), but I did an informal review of your package
> and put my notes in the bugzilla ticket.
Thanks. I notice that emails from the Red Hat bugzilla take nearly a
day to reach me. Is that expected?
Thanks for catching my mistake; it is all intended to be LGPLv3.
I'll post an updated build + spec file to the bug;
any other steps I should take?
Cheers,
Jeremy
11 years, 3 months
Fedora ARM weekly status meeting 2013-02-13
by Paul Whalen
Good Morning all,
Please join us today (Wednesday, February 13th) at 4PM EST (9PM UTC)
for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode.
On the agenda so far..
0) Status of ACTION items from our previous meeting
1) Problem packages
2) Kernel updates in F17, F18 causing issues
3) Mass rebuild - Adding additional HSV builders, status update
4) Open Floor
If there is something that you would like to discuss that isn't mentioned
please feel free to bring it up at the end of the meeting or send an email
to the list.
Paul
11 years, 3 months
Should MariaDB touch my.cnf in %post?
by Honza Horak
Hi folks,
I'd like to share an idea related to MySQL->MariaDB move, that may be a
bit controversial. Speaking about default case in Fedora, MySQL has used
only one file at /etc/my.cnf to configure server, libraries,
command-line utilities, etc.
MariaDB uses by default /etc/my.cnf and
/etc/my.cnf.d/{client,server,..}.cnf files, while all the /etc/my.cnf.d
directory is included using !includedir statement in /etc/my.cnf.
The problem is, that after replacing MySQL with MariaDB existed my.cnf
won't get updated (uses "%config(noreplace)") and then users will be
confused by having /etc/my.cnf.d/* files, which won't be used.
A solution proposed by MariaDB upstream would be adding !includedir
directive into /etc/my.cnf (if not already done) in mariadb's %post
section. That would mean *modifying user's configuration during RPM update*.
I haven't found any restriction forbidding this solution, but would like
to collect opinions, how bad it is, because we're aware it's not very
clean -- however, it has it's benefits.
In case user won't wish to use !includedir anymore, he'd comment it out
and it won't get added again.
Cheers,
Honza
11 years, 3 months