cc'ing to devel list as well.
On 29 May 2014 11:26, pravin.d.s(a)gmail.com <pravin.d.s(a)gmail.com> wrote:
> Glad to see this happening after long time.
> On 29 May 2014 10:25, Parag Nemade <pnemade(a)redhat.com> wrote:
>> It took some time but finally we have a working
>> system-config-language tool in Fedora rawhide. The major changes
>> happened from 1.4.1 release to this 2.1.0 release are
>> 1) system-config-language GUI is re-written using PyGobject3 API's.
>> 2) system-config-language checks packages to install for any language
>> using yum-langpacks instead of groups in comps file.
> Earlier s-c-l was using groupinstall which used to install fonts, IMES and
> l10n related packages. yum-langpacks only install l10n related package.
> If i remember correctly Bill mentioned earlier, intention behind langpack
> is to get rid of language related group and also mentioned
> https://bugzilla.redhat.com/show_bug.cgi?id=840885#c21 "
> The groups are likely to be removed soon - input methods merged into the input-methods group, and fonts into the font group."
> But question arise if layman users want to install IME and fonts packages
> related to his language, how he can accomplish that? With the present
> implementation either he need to install all fonts and IME's available in
> systems to get his desired language related package. This is definitely
> what we are looking for.
> I strongly feel langpacks should be compatible with "groupinstall
> lang-support" in long term.
> Pravin Satpute
= Proposed System Wide Change: cron to systemd time units =
Change owner(s): Jóhann B. Guðmundsson <johannbg AT gmail DOT com>
Fix dependency on crontab in packages containing cron jobs as well as migrate
cron jobs that are applicable to native systemd timer units.
== Detailed description ==
Add dependency on crontab in packages containing cron jobs as well as migrate
cron jobs that are applicable to native systemd timer units in packages that
already depend on systemd.
== Scope ==
* Policies and guidelines:
** Adjust packaging guidelines to fix dependency in cron packages [Package Cron
Files 1] DONE
** Adjust packaging guidelines to mention migration of cron jobs to timer
units for packages that already depend on systemd
* Fix spec files in packages that are not applicable for migration [Fix Cron
Dependency Tracking Bug 2]
* Review and migrate if applicable cron jobs shipped in packages that already
depend on systemd [Timer Migration Tracking Bug 3]
* Update systemd wikipage to contain timer units example
devel-announce mailing list
Once upon a time (Fedora 15? -- I've lost track), it was possible to
reinstall the bootloader using grub-install.
Nowadays it's a clusterfsck. I've managed to screw up my bootloader. Is
there a way to reinstall it without reinstalling the world? Would it make
sense to split the whole bootloader thing out of Anaconda such that it
would be possible to re-run it? I can access my install just fine using
FWIW, the same question applies to upgrading the bootloader. Somehow I'm
on Fedora 20 using grub 0.97.
Is this wasteful new dependency on Nokia intentional?
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see
spec.diff) and built the package:
$ rpmbuild -ba bind.spec
The package builds and BIND itself seems to work. The problem is that new
debuginfo package is missing 118 out of 283 header files in
It seems that "-O0" alone (instead of "-O0 -ggdb") causes the same problem.
I would be glad if anyone can give me advice how to debug this.
Original packages from Fedora 20 (with all headers in /usr/src/debug):
Packages built with -O0 -ggdb (scratch build):
Thank you for your time!
Hi, folks! So, I quickly bashed out that draft F21 Test Plan I've been
threatening to write for the last month or so.
So, what's the idea here?
Really, I'm just trying to come up with a starting point for all the
decisions we need to make and planning we need to do for Fedora 21
testing, especially release validation testing, especially as regards
Fedora.next. There's some mention of other stuff in there, but what I'm
really trying to think about is what we need to do to extend our test
processes to cover all the stuff that's coming as a part of .next.
I think the most interesting points are these:
* There are several practical implications from the test plan - just
Work We Need To Do. Most obviously, we need to draw up release criteria
and supporting test cases for the Fedora.next Products. We also will
need to adjust the
to include those cases/matrices as they're created, and adjust the
https://fedoraproject.org/wiki/Release_criteria page to refer to/include
the Product-specific release criteria as *they're* created.
* Responsibilities! Particularly, in this *draft* Test Plan, I've
suggested that creating the Product-specific criteria and test cases
should be the responsibility of the relevant Working Groups, with
assistance from the QA team. They would also be jointly responsible,
along with the QA team, for conducting Product-specific testing, on the
general principle that the more Product-specific a bit of testing is
(and the more domain-specific expertise it needs), the more it's the
WG's responsibility and the less it's QA's responsibility. Note that
(again, as a suggestion in this draft) the QA team is still responsible
for Fedora 21 testing *overall* - i.e. it's the QA team's responsibility
to make sure the WGs do the stuff assigned to them in the plan. If that
makes sense. Discussion welcome!
* Feasibility. This is, of course, one I really want to nail down. It
will require, though, that the Product-specific release criteria and
test cases / matrices get written. Once we have those, we can try and
make a realistic judgement as to whether we as a project - the QA team
and the WGs - actually have the resources to complete the minimal
necessary level of testing within the scope of the F21 schedule. If we
don't think that's going to be the case, we can take that to FESCo, and
we can decide what to do about it that way. In the meantime I've
provided a *very* vague 'Required resources' section just to sort of
flag this up in a modest way.
I'd really, really appreciate feedback on this draft from all interested
parties - QA folks, WG folks, FESCo, anyone at all reading this who has
an opinion. Please, bikeshed away. It all helps.
I'll aim to kick off discussion between the WGs and QA about creating
Product-specific release criteria and test cases next week. Obviously
that's *somewhat* subject to feedback on this very draft, but I can't
really envisage a world in which we aren't going to need those two
things to happen, and whoever's job we ultimately decide it is, I don't
*think* that me just kicking off an attempt to draft them can be a bad
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> From: Matthew Miller <mattdm(a)fedoraproject.org>
> To: Development discussions related to Fedora
> Subject: Re: Self Introduction: Jeff Schroeder
> Message-ID: <20140527131351.GB7103(a)mattdm.org>
> Content-Type: text/plain; charset=us-ascii
> On Sun, May 25, 2014 at 01:34:25PM -0500, Jeff Schroeder wrote:
> >  http://serfdom.io
> >  http://consul.io
> Hi Jeff! Welcome! These look pretty interesting. Do you think they're worth
> integrating with GearD as a possible part of Fedora Atomic?
> Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
> "Tepid change for the somewhat better!"
While I don't think it should necessarily be a required dependency I think
the answer to your question is a resounding yes! Geard is fantastic
software that builds ontop of docker. There isn't a good reason for geard
to re-implement docker any more than there is for geard to re-implement
zookeeper or consul. For large multi-node deployments (1000+), I think
service discovery is a must. This is why I'm interested in it, my problems
are solved cleanly through good service discovery and I'd like to do it the
"proper" way, making Fedora / EPEL better in the process.