On Sun, Mar 17, 2013 at 8:10 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
> Am 18.03.2013 01:06, schrieb Nico Kadel-Garcia:
>> On Sun, Mar 17, 2013 at 12:36 PM, Peter Lemenkov <lemenkov(a)gmail.com> wrote:
>>> 2013/3/15 Lukáš Nykrýn <lnykryn(a)redhat.com>:
>>>> After usr move packages should not install files to /sbin. Unfortunately
>>>> there is a lot of packages requiring /sbin/service, which was recently moved
>>>> to /usr/sbin/, and these packages were uninstallable. As a workaround I have
>>>> put Provides: /sbin/service in the initscript spec, but I think that we
>>>> should do a proper fix.
>>>> So if your package is in following list, please change your Reguires to
>> This is a bad, bad, bad idea for any packages that are going to remain
>> backwards compatible with RHEL, for compilation under EPEL or other
>> backporting. Either switch to systemd, or stick with the old location
>> and allow initscripts to correctly include the old reference. Do not
>> pick a hallfways "fix" that isn't backwards compatible at all.
> * Fedora has done UsrMove with F17
> * Now we have F18
> * in a short we have F19
> * RHEL7 will be base on F18/F19
> ANY reference in Fedora to /sbin and /bin is BOGUS
> it leads to all sorts of troubles
> it leads to additional symlink reslovement
If SysV init style scripts are staying in use, even as a compatibility
fallback, don't edit the references to them just to prove something.
It breaks backporting and forward porting and cross-compatibility for
every existing versoin of RHEL, which are still needed for
compatibility because *systemd can't be ported back to RHEL 6 or
earlier.* I've tried, it's a dependency and critical component upgrade
# Fedora Quality Assurance Meeting
# Date: 2013-03-18
# Time: 15:00 UTC
# Location: #fedora-meeting on irc.freenode.net
It's meeting time again tomorrow / today! We should be doing Alpha TC1
this week, so we need to look at the status of current F19 and see what
needs to be done to make that happen. We can discuss my criteria
revision proposal further, and follow up on last week's KDE Test Day and
make plans for this week's GNOME Test Day.
This is a reminder of the upcoming QA meeting. Please add any topic
suggestions to the meeting wiki page:
The current proposed agenda is included below.
== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Fedora 19 Alpha status
3. Criteria re-design
4. Test Days
5. Open floor
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
test-announce mailing list
I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. Grub in particular is problematic, with a starfield background that looks like a Fedora background from a few releases ago and a progress bar that indicates the progress in 'booting the bootloader'.
There are also some issues on the login screen, with Fedora logo being at small-print size right now.
I think a few simple changes we can make a big improvement to the visual experience for F19:
- Turn off the graphical grub screen
Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock..., avoiding the graphical screen will be a win in terms of reduced visual noise.
- Switch to a simple spinner for the plymouth theme
This theme is available in plymouth today: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock...
I know when we've proposed this in the past, there was concern about loosing the one place where the Fedora logo is visible in the boot. I'd like to propose a compromise that will keep the Fedora logo _and_ improve the transition to the login screen: How about we use the spinner as in that mockup, but add a reasonably-sized Fedora logo in the top left corner.
- Replace the small print logo on the login screen with a bigger one
The idea here is to replace the small-print Fedora text logo that we currently have in that corner by the same Fedora logo thats used in plymouth, so that it remains unchanged as we transition from plymouth to gdm.
What do you think ?
So I installed fedora-release from the F19 repo and did a yum
distro-sync today. Then I installed a new kernel build. Then I rebooted.
Then nothing would boot at all.
It turns out this is because the release name of Fedora 19 is:
with a single quote used as an apostrophe. That release name gets
written into the grub entry for a kernel when you're installing it.
Unfortunately, the lines it goes onto look like this:
menuentry 'Fedora (3.9.0-0.rc2.git0.4.fc20.x86_64) 19 (Schrödinger's
Cat)' --class fedora --class gnu-linux --class gnu --class os
echo 'Loading Fedora (3.9.0-0.rc2.git0.4.fc20.x86_64) 19 (Schrödinger's
note how both lines use single quotes for quoting. The single quote in
the release name terminates the quotes early, and leaves the rest of the
stuff that's meant to be inside the single quotes as garbage lying
around the config file.
The upshot of this - for me anyway - is that the entry for the offending
kernel didn't show up on the grub menu at all, and neither of my other
kernels would boot, though they did appear (somehow, this borkage causes
grub not to pass in any kernel parameters). So I was kinda stuck.
The fix was to boot live, mount my /boot partition, edit the grub config
file, and take the single quotes out of all occurrences of
"Schrödinger's Cat". I also replaced the umlauted o (that was my first
guess at the cause of the problem), but I'm not sure if that's necessary.
So - don't get bitten by this :) If you really want to get on the F19
branch, then just make sure you hand-check your grub config file before
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
I am a system engineer at ORINUX BURUNDI. I am not experienced in big
development project. But i love programming and design.
However, i have been using fedora for years and building personal
application in c, c++, java, python and assembly. And also i did some
scripting with shell.
Therefore, i really want to participe in fedora development while learning
and sharing my small experience.
Please any guidelines or mentor are the most welcome to help.
On Feb 12, Honza Horak wrote:
>> grep -q '!includedir /etc/my.cnf.d' /etc/my.cnf || \
>> (echo; echo '!includedir /etc/my.cnf.d') >> /etc/my.cnf
> Thanks for that idea. It would work, but honestly I'm not sure if we
> want touch my.cnf during update. I've shared this idea with other
> fedora developers to collect their opinions -- feel free to join the
> discussion at:
So, here I am, replying...
On Feb 12, Reindl Harald wrote
> any real used mysqld will have a customized /etc/my.cnf and no admin
> should do this migartion without take really care what happens and
> test this before - unclean soltutions will hurt sooner or later
> in moments where this is not expected
The solution in my email was clean, as far as I could see.
/etc/my.cnf.d directory is empty in our packages (there are files in it,
but they contist of comment lines only), so it cannot break anything if
added to my.cnf
On Feb 12, Toshio Kuratomi wrote
> There are several reasons that user's config files shouldn't be touched:
> * Possibility of getting the change to the user's config wrong is very high
> as user's can change their config in arbitrary ways. Do you handle the
> case where a user has added their own includedirs? Do you handle the case
> where a user has commented out their own includedir? Do you handle the
> case where a user has a comment about includedir? Do you handle the case
> where a user has deleted the includedir line? There are many corner cases
> that can be missed here.
Yes, it handles the case where a user has added his own includedirs.
Yes, it handles the case where a user has commented out his own includedir.
Yes, it handles the case where a user has a comment about includedir.
Yes and no. If the user has deleted the includedir line, it will be
added back. It is, probably, not what the user wants [thus "no"], but
achieves exactly the same effect as the other proposed solution
(automatically read files in /etc/my.cnf.d/ no matter what's in
/etc/my.cnf) [thus "yes"]
> * User expectation is currently that their configs aren't going to change on
> version upgrade. Instead, they need to look for .rpmnew and .rpmsave
> files to tell them if anything has changed that they need to be aware of.
> A user updating to F19 won't be expecting that files in /etc/my.cnf.d
> should affect their installation if they didn't have to migrate that over
> from the my.cnf.rpmnew file themselves.
Okay, so you suggest to do nothing - neither append the includedir line
to the existing my.cnf nor let mariadb read /etc/my.cnf.d/ automatically
That's fine :)
I was only trying to find an alternative to "let mariadb read
/etc/my.cnf.d implicitly" - because I don't like an idea of adding more
magic to the server, it has more than enough of it already.
I would like to package some additional catalogs for Skychart, but I
have some questions regarding license and to the package process.
First of all, as you can see on skychart download page , each package
has more than one catalog inside. All of these catalogs are known to be
public domain, but there's no license file specified either in catalogs
or on original websites of the catalogs  . Moreover, original
catalog data is reworked by skychart's developer to fit the main program.
So, questions about license: Should I ask for a license file to be
integrated? Who I should ask for the license file, skychart's developer
or who make the original catalog data?
Now the technical questions. I suppose I must create new packages and
requesting reviews for each catalog source instead of creating
subpackages inside the main skychart specfile, right? For example,
skychart-data-stars.spec will have stars catalogs and
skychart-data-dso.spec will have dso catalogs, like on the skychart's
But what if inside the stars catalogs package two catalogs have
different licenses?I must create different subpackages, right?
Final question. Since all these catalogs contain only data that only
requires to be copied in the appropriate directory, there's no need to
build anything. Can the specfile have a void %build section?
...well, quite a lot of questions! ;-) I hope someone can clarify me on