Re: Building upstream kernel with Fedora config

[Thorsten Leemhuis]

On 07.06.24 08:04, Thorsten Leemhuis wrote:
> On 06.06.24 17:47, Justin Forbes wrote:
>> On Thu, Jun 6, 2024 at 9:19 AM Thorsten Leemhuis  
>> wrote:
>>> On 04.06.24 18:12, Mikhail Gavrilov wrote:
>>>
>>>> Instruction [1] about building upstream kernel should be updated,
>>> I'd tend to disagree. I think the root of the problem should be fixed,
>>> which you...
>>>
>>>> because since commit 5e6abd7f4dce [2] the Fedora kernel config contain
>>>> CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem"
>>>
>>> ...describe here. That's because other people will run into the problem
>>> elsewhere then using localmodconfig and such -- like it is the case for
>>> Debian already:
>>> https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html#configmods-distros
>>>
>>> Did anyone report this to kernel-ark already? Or checked with kernel-ark
>>> commit caused this?
>>
>> The docs are what should be updated.
> 
> Why not do something like "sed -i
> s!CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem!#
> CONFIG_SYSTEM_TRUSTED_KEYS is not set" in the %install section (or
> somewhere else once the kernel was built and the .config put aside for
> shipping) to ensure things like "make localmodconfig" and "make
> olddefconfig" work when using the .config from Fedora's kernel as a base
> (among others for bisecting a upstream bug).
> 
> Alternatively: why not ship that file properly in some package that
> becomes a Requirement? Then things would work for everyone doing the
> above, too.

Hmm, no reply here. So I put those ideas into a ticket now, maybe I get
a reaction there: https://gitlab.com/cki-project/kernel-ark/-/issues/158

Ciao, Thorsten
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Building upstream kernel with Fedora config

[Thorsten Leemhuis]

On 06.06.24 17:47, Justin Forbes wrote:
> On Thu, Jun 6, 2024 at 9:19 AM Thorsten Leemhuis  wrote:
>>
>> On 04.06.24 18:12, Mikhail Gavrilov wrote:
>>
>>> Instruction [1] about building upstream kernel should be updated,
>> I'd tend to disagree. I think the root of the problem should be fixed,
>> which you...
>>
>>> because since commit 5e6abd7f4dce [2] the Fedora kernel config contain
>>> CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem"
>>
>> ...describe here. That's because other people will run into the problem
>> elsewhere then using localmodconfig and such -- like it is the case for
>> Debian already:
>> https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html#configmods-distros
>>
>> Did anyone report this to kernel-ark already? Or checked with kernel-ark
>> commit caused this?
> 
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3160 is the
> commit which introduced it and it is a good change overall.

Thx.

> The docs are what should be updated.

Why not do something like "sed -i
s!CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem!#
CONFIG_SYSTEM_TRUSTED_KEYS is not set" in the %install section (or
somewhere else once the kernel was built and the .config put aside for
shipping) to ensure things like "make localmodconfig" and "make
olddefconfig" work when using the .config from Fedora's kernel as a base
(among others for bisecting a upstream bug).

Alternatively: why not ship that file properly in some package that
becomes a Requirement? Then things would work for everyone doing the
above, too.

>  Of note, the generated configs in
> dist-git and the srpm do not have this line, it is only there after we
> prep, so they do offer a fine place to start.

But all that makes things distro specifc and requires people to known
that and read docs (which most of them will not). :-/

Ciao, Thorsten
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Building upstream kernel with Fedora config

[Thorsten Leemhuis]

[CCing Justin]

On 04.06.24 18:12, Mikhail Gavrilov wrote:

> Instruction [1] about building upstream kernel should be updated,

I'd tend to disagree. I think the root of the problem should be fixed,
which you...

> because since commit 5e6abd7f4dce [2] the Fedora kernel config contain
> CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem"

...describe here. That's because other people will run into the problem
elsewhere then using localmodconfig and such -- like it is the case for
Debian already:
https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html#configmods-distros

Did anyone report this to kernel-ark already? Or checked with kernel-ark
commit caused this?

Ciao, Thorsten
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Announcing creation of Fedora Source-git SIG

[Thorsten Leemhuis]

On 14.04.21 10:45, Tomas Tomecek wrote:
> Good morning, I'd like to announce the creation of Fedora Source-git SIG:
> https://fedoraproject.org/wiki/SIGs/Source-git
> 
> Our main goal in the SIG right now is to establish a development
> workflow for Fedora Linux packages using repositories with sources and
> upstream history (this is what we call source-git), instead of just
> distribution files with links to tarballs (dist-git).

Just wondering: will there be some coordination with the Fedora kernel
developers that are relying on a git based workflow since a few
weeks now (for rawhide even longer)?

To those who don't know: all the stuff in dist-git kernel is
generated from https://gitlab.com/cki-project/kernel-ark these days
afaik, so it might be wise to make sure the solution you work out works
for them as well. Especially as I find find some parts of how they do it
a bit questionable. The main tarball they use as Source0 for example
doesn't match the tarball downloadable from kernel.org(¹); all the
patches are stashed into one(²); patches for fedora specific stuff (like
the configs needed for building the kernel) are in the same branch as
the patches(³). I think that makes things quite confusing, especially
for outsiders. Sometimes I wonder if some of what the kernel people do
violates the Fedora Packaging Guidelines(⁴), but the kernel-ark people
ensured me it's fine.

CU, knurd

(¹)
https://src.fedoraproject.org/rpms/kernel/blob/f33/f/sources for example
states:
> SHA512 (linux-5.11.14.tar.xz) = 
> ccf0eaf6df0dacd2984c361621f67a3d16cf7a7174155ebdf646f1acfec43e19ff942e6c17e5bc3b5dc7a300c32bdc6ee37877162c099f5bd9924244f9445467
But:
$ wget --quiet
https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.14.tar.xz
$ sha512sum linux-5.11.14.tar.xz
8dfc7ff184e5cb33fff74686071f1605f3a834669e201d272f3047aa00657339ec1a3cfd605d8761b8a0f335b8488c02c701e72ed30031856e9c154aa1ff2d88
 linux-5.11.14.tar.xz


(²)
https://src.fedoraproject.org/rpms/kernel/blob/f33/f/patch-5.11-redhat.patch
FWIW, links to the individual patches can be found here:
https://src.fedoraproject.org/rpms/kernel/blob/f33/f/Patchlist.changelog

(³) for example
https://gitlab.com/cki-project/kernel-ark/-/commits/fedora-5.11

(⁴) like this part "sources used to build a package should be the
vanilla sources available from upstream. To help reviewers and QA
scripts verify this, the packager needs to indicate where a reviewer can
find the source that was used to make the rpm". The quote is from here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ars claims: Fedora 32 is sluggish

[Thorsten Leemhuis]

Am 11.02.21 um 15:28 schrieb Peter Robinson:
> On Thu, Feb 11, 2021 at 1:03 PM Ondrej Mosnacek  wrote:
>> On Thu, Feb 11, 2021 at 10:14 AM Viktor Ashirov  wrote:
>>> On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro  
>>> wrote:
> […]
>>> This was bugging me for a while. I also noticed that Fedora 32 is a bit 
>>> slower than it used to be. Compilation time of a project that I'm working 
>>> on went from ~35-36 seconds to ~47-48. At first I thought that it's just 
>>> another round of CPU vulnerabilities mitigations that introduced a 
>>> performance drop. But after some digging I found that the default CPU 
>>> governor was switched from 'ondemand' to 'schedutil' in Fedora kernel 5.9.7:
>  […]
> It was upstream changes, the Intel maintainer changed it in [1] if
> X86_INTEL_PSTATE state was selected in late March which would make
> sense in the timg, and also changed for arm arches [2] in July.
> 
> If that change was made upstream I'm assuming it was assumed that
> performance should be equivalent or better than the other option, I
> suspect we should engage with upstream as they're probably interested
> in the issues.

FWIW, I wonder if some changes that were merged for mainline this week
might be related:

https://git.kernel.org/torvalds/c/291009f656e8eaebbdfd3a8d99f6b190a9ce9deb
https://git.kernel.org/torvalds/c/d11a1d08a082a7dc0ada423d2b2e26e9b6f2525c
https://git.kernel.org/torvalds/c/3c55e94c0adea4a5389c4b80f6ae9927dd6a4501

But I'm not entirely sure what CPUs are affected by d11a1d08a082

HTH, CU, thl
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Using amdgpu as default for all GCN cards

[Thorsten Leemhuis]

Lo! On 25.09.2017 20:28, Luya Tshimbalanga wrote:
> On 25/09/17 04:51 AM, Kamil Paral wrote:
> […] 
> So far, Sea Island cards are enabled by default from kernel 4.13.x while
> only the old GCN cards (South Island) are the last to remain
> experimental.

Source? Afaics it's more like: Yes, GCN is considered experimental, but
even if you enable the amdgpu support for CIK parts you have to provide
two module parameters on boot to activate it -- hence you can't really
call that "Sea Island cards are enabled by default" imho. See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/Kconfig
for details (it's the same in 4.13). That stuff was changed quite a bit
for 4.13; one of those commits was
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b059658d6796a096ef06be9da994d6c44401d5b
which reads "There is no feature parity yet for CIK, in particular
amdgpu doesn't support HDMI/DisplayPort audio without DC."

For me all of this says: It's way to early to switch to amdgpu for GCN
or CIK GPUs.

CU, knurd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Thorsten Leemhuis]

On 05.09.2017 18:59, James Hogarth wrote:
> On 5 Sep 2017 5:42 pm, "Laura Abbott"  > wrote:
>
> Kernel 4.13 was released this past weekend. This kernel has been
> built for rawhide and is building for F27 as well. We will be
> following the same upgrade procedure as in the past. F25 and F26
> will get rebased to 4.13 after a few stable releases, typically
> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
> does not give release dates for stable release but given past
> timings, this will probably happen towards the end of September.
> As always, if you have any questions please let me know.
> Thanks for the heads up Laura
> Will there be a stabilization COPR for us to test the builds against/on F26?

Shameless plug: If you want to get Linux 4.13 now you can also run this:

curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo |
sudo tee /etc/yum.repos.d/kernel-vanilla.repo
sudo dnf --enablerepo=kernel-vanilla-stable update

This will install a vanilla kernel from the kernel vanilla stable repo,
where is landed yesterday. For more details and other kernel vanilla
repos (mainline, mainline-wo-mergew & fedora) please see
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories &
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories-FAQ

HTH, CU, knurd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Thorsten Leemhuis]

Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
> [...]
> ## Advantages
> 
> * Simplification of build-tree creation. We wouldn't have to maintain the 
> lists
> and hacks that are required to make sure that multilib packages land in the
> correct repositories.
> [...]

Just wondering: Why don't we switch to a multilib/multiarch solution
similar to the one that Debian/Ubuntu uses? They put libs in directories
like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu
(https://wiki.debian.org/Multiarch/Implementation
https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar
solution a new (de facto) standard might evolve and in the end nobody
would have to deal with hacks any more, because all major distros would
put libs in the same directories. Iirc their model has benefits for
cross-compilation, too.

Cu, knurd



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM %changelog?

[Thorsten Leemhuis]

On 23.10.2016 19:31, Richard W.M. Jones wrote:
> On Sun, Oct 23, 2016 at 10:37:17AM -0400, Neal Gompa wrote:
>> In Mageia, we use the VCS log as input to dynamically generate the RPM
>> changelog and append it to the spec as part of the SRPM build process
>> for the package build.
> This would be far better than the current situation IMHO.  There's no
> point in inaccurately duplicating information twice, [...]

Hmmm. I think I don't consider it duplicated information. A commit
messages in the VCS afaics is something that is written for other
developers that want to understand/track changes (now or in the future).
The intent of the changelog OTOH "is to give the user a hint as to what
changed in a package update" (quote from
https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs ).

IOW: Different target audiences. And that's why the messages [c|sh]ould
differ. But they often don't. But maybe that's just us being lazy? (yes,
I'm guilty in this regard ;-) )

CU, knurd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Thorsten Leemhuis]

Peter Robinson wrote on 12.05.2016 10:11:
>>> = Proposed System Wide Change: Use /etc/distro.repos.d as default reposdir =
>>> https://fedoraproject.org/wiki/Changes/ReposInEtcDistroReposD
>>>
>>> Change owner(s):
>>> * Neal Gompa 
>>> * Jan Silhan 
>>>
>>>
>>> == Detailed Description ==
>>> For DNF 2.0 in Fedora 25, the DNF team would like to make the default
>>> repository configuration directory /etc/distro.repos.d. In contrast to
>>> /etc/yum.repos.d (current default path), /etc/distro.repos.d path is a
>>> package manager agnostic name and less misleading. The configuration
>>> files are currently used by DNF, PackageKit, and Yum. The proposed
>>> location more accurately reflects the nature of the repositories, and
>>> also implies that other tools can look there for repository
>>> information. Note: current default repository configuration directory
>>> /etc/yum.repos.d will still be supported by package managers but
>>> /etc/distro.repos.d would be preferred default path.
>>
>>   Shouldn't that be /usr/lib/distro.repos.d (for distribution-provided
>> data) with usual rules for overriding/masking in /etc/distro.repos.d (for
>> local administrator)?

+1 -- I just wanted to write something similar!

> So if you just want to enable updates-testing you have to copy files around?

I'd prefer a scheme similar to systemd, where you in
/etc/systemd/system/ can easily extent or overlap units defined in
/usr/lib/systemd/system/ See
https://www.freedesktop.org/software/systemd/man/systemd.unit.html for
details.

CU
knurd
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Can soft dependencies help to get the proper kernel-devel packages? (Was: Soft- Re: DKMS is not installing the right kernel-devel package)

[Thorsten Leemhuis]

Josh Boyer wrote on 12.06.2015 13:55:
 On Fri, Jun 12, 2015 at 7:24 AM, Neal Gompa ngomp...@gmail.com wrote:
 [...]
 As I said, there are no great solutions here.

A works most of the time-solution would be: Install kernel-devel by
default. But I'm not seriously suggesting that, because I fully agree:
It's not a great solution.

Did anyone(¹) look at soft dependencies in rpm? Can they make our
tools install the kernel-devel packages in the variants that match the
kernel variants installed? I suspect they are made to solve problems
like this, but I'm not sure; and I don't know how far soft dependencies
are supported in out current stack of packaging tools.

CU
knurd

(¹) no, I'm not looking at you Josh

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DKMS is not installing the right kernel-devel package

[Thorsten Leemhuis]

Dan Book wrote on 09.06.2015 22:01:
 This has also been a problem for several releases with the akmods from
 rpmfusion.

There was always a problem; there where just less people running into
it, because yum/dnf installed kernel-devel most of the time, which
matched the kernel that was running on most systems; but quite a few
x86-32 users ran into problems afaics, as kernel-PAE get's installed
there sometimes and hence they needed kernel-PAE-devel.

Mosts of the docs and howtos on the net don't mention that, which leads
to confused and frustrating users; those in the end might be one of
multiple problems why they switch to another distribution.

 I think the more correct solution (read to the end) would
 be to somehow prioritize the kernel-devel package (possibly multiple)
 that matches the installed kernel(s).

That's not a solution, that's solving the problem for some users and
ignoring others (those that use kernel-PAE for example).

 [...]

CU
thl

 On Tue, Jun 9, 2015 at 3:41 PM, Thorsten Leemhuis fed...@leemhuis.info
 mailto:fed...@leemhuis.info wrote:
 
 On 09.06.2015 21:04, Neal Gompa wrote:
  I've noticed that when dkms is installed, it's not grabbing the right
  kernel-devel package as a dependency.
 
 Because that's not possible with ordinary dependencies (might be
 possible with soft dependencies [Suggests, Enhances etc]) unless we
 change something in the kernel packaging (see below).
 
  Instead, it grabs
  kernel-debug-devel. This occurs on Fedora 21 and 22, and I'm not sure
  why.
 
 Because all kernel*devel package provide kernel-devel iirc.
 
  Anyone have any idea why this is happening and a way to work around it?
 
 Create something like a meta-package kernel-devel-all that depends on
 all available kernel-devel packages (kernel-devel, kernel-PAE-devel,
 kernel-debug-devel, ...) for the arch in question; then add Requires:
 kernel-devel-all to the akmods and dkms packages. That's messy and
 creates overhead for users, but that's afaics the only way it will work
 for everyone; otherwise you'll always run into situations where a
 kernel-devel package for one kernel variant gets installed while you are
 running different variant. Example: You get kernel-devel via some
 dependency in akmods or dkms; but you are running kernel-PAE on your
 i686 machine, so building modules with akmods or dkms will fail, as
 that's requires kernel-PAE-devel.
 
 HTH; CU, knurd
 --
 devel mailing list
 devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 
 
 
 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DKMS is not installing the right kernel-devel package

[Thorsten Leemhuis]

On 09.06.2015 21:04, Neal Gompa wrote:
 I've noticed that when dkms is installed, it's not grabbing the right
 kernel-devel package as a dependency. 

Because that's not possible with ordinary dependencies (might be
possible with soft dependencies [Suggests, Enhances etc]) unless we
change something in the kernel packaging (see below).

 Instead, it grabs
 kernel-debug-devel. This occurs on Fedora 21 and 22, and I'm not sure
 why.

Because all kernel*devel package provide kernel-devel iirc.

 Anyone have any idea why this is happening and a way to work around it?

Create something like a meta-package kernel-devel-all that depends on
all available kernel-devel packages (kernel-devel, kernel-PAE-devel,
kernel-debug-devel, ...) for the arch in question; then add Requires:
kernel-devel-all to the akmods and dkms packages. That's messy and
creates overhead for users, but that's afaics the only way it will work
for everyone; otherwise you'll always run into situations where a
kernel-devel package for one kernel variant gets installed while you are
running different variant. Example: You get kernel-devel via some
dependency in akmods or dkms; but you are running kernel-PAE on your
i686 machine, so building modules with akmods or dkms will fail, as
that's requires kernel-PAE-devel.

HTH; CU, knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: RFC: xserver update strategy in F21+

[Thorsten Leemhuis]

Lo!

Adam Jackson wrote on 17.11.2014 20:06:

 With that in mind, I ask for feedback on how we'd actually like that to
 work.  The kernel rebase policy seems like a pretty reasonable model:
 F21 would stay on 1.16.x until there's an upstream 1.17.1 release, and
 (if F20 were to be affected by this policy) F20 would wait until 1.17.1
 had been tested in F21.
 
 One thing we might have to play by ear is the interaction with binary
 drivers.  The nvidia legacy driver, for instance, does not always have
 builds available for arbitrarily new servers, which means updating the X
 server might change you to an nvidia driver that no longer supports your
 hardware.  Depending on how severe that cutoff is, it might be cause to
 pin a particular Fedora release at a given server version.  I don't
 think this is presently a problem, but it could be in the future.

The same problem can and did arise with the kernel updates Fedora does.
Fglrx/catalyst in the past more than once got broken when Fedora shipped
a new major version (3.x - 3.(x+1)) as a regular update, because the
flgrx/catalyst kernel module the flgrx/catalyst driver for X.org relies
on was incompatible with the new kernel. Sometimes (but not always!)
there were patches to work around that (and yes, they often got
integrated into RPM Fusion packages).

But in the end Fedora and its kernel maintainers didn't care. Which
might be the right thing to do for X as well, because companies then
learn that they need to keep track of ongoing development and users
notice some of the risks these driver bear.

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: btrfs as default filesystem for F22?

[Thorsten Leemhuis]

Thorsten Leemhuis wrote on 08.10.2014 07:52:
 Josh Boyer wrote on 07.10.2014 21:15:
 On Tue, Oct 7, 2014 at 2:24 PM, Josef Bacik jo...@toxicpanda.com wrote:
 […]
 I think the point is somewhat valid though. To just keep repeating the
 mantra 'its not ready' is not going to make it any more ready. If suse
 can identify a stable subset of btrfs features and use it as their
 default file system with those restrictions, why can't we do the same ?
 The approach makes sense to me, at least...
 Because they still have the support staff for when users don't listen,
 Fedora doesn't.
 As an aside, I looked at their 3.16.2-1.1.gdcee397 kernel-source SRPM.
 I can't find any patches that limit btrfs usage.  I could totally be
 wrong, but if someone knows of a patch that limits the features please
 point me to it.
 
 Due to a coincidence I yesterday took a quick look myself and didn't
 spot anything. But in case you haven't looked further: I found one in
 the SLE-Kernels:
 
 http://kernel.opensuse.org/cgit/kernel-source/tree/patches.suse/btrfs--add-allow_unsupported-module-parameter.patch?h=SLE11-SP3
 http://kernel.opensuse.org/cgit/kernel-source/tree/patches.suse/btrfs--add-allow_unsupported-module-parameter.patch?h=SLE12

BTW  TWIMC, their solution to problems like this
http://aseigo.blogspot.de/2014/09/btrfs-rebalancing.html (ran into this
myself yesterday) seems to be a package called btrfsmaintenance that was
introduced a few days ago. Quoting
http://article.gmane.org/gmane.linux.suse.opensuse.devel/59787/

 From: David Sterba dsterba at suse.cz
 Subject: Introduce btrfsmaintenance package to Factory
 Newsgroups: gmane.linux.suse.opensuse.devel
 Date: 2014-10-06 15:40:37 GMT (1 day, 14 hours and 40 minutes ago)
 
 Hi,
 
 let me introduce a new package that supplements the btrfs filesystem and aims
 to automate a few maintenance tasks. This means the scrub, balance, trim or
 defragmentation. The package comes from SLE12 where btrfs is going to be the
 default filesystem as well.
 
 Each of the tasks can be turned on/off and configured independently. The
 default config values were selected to fit the default installation profile.
 
 * scrub - go through all medatada/data and verify the checksums, default 
 period
 is one month
 
 * balance - the balance command can do a lot of things, in general moves data
 around in big chunks, here we use it to reclaim back the space of the
 underused chunks so it can be allocated again according to current needs
 
 The point is to prevent some corner cases where it's not possible to eg.
 allocate new metadata chunks because the whole device space is reserved for 
 all
 the chunks, although the total space occupied is smaller and the allocation
 should succeed.
 
 * trim - run TRIM on the filesystem using the 'fstrim' utility, makes sense 
 for
 SSD devices.
 
 * defrag - run defrag on configured directories. This is for convenience and
 not necessary.
 
 There's a separate defragmentation task that happens automatically and
 defragments only the RPM database files in /var/lib/rpm. This is done via a
 zypper plugin and the defrag pass triggers at the end of the installation.
 
 This improves reading the RPM databases later, but the installation process
 fragments the files very quickly so it's not likely to bring a significant
 speedup here.
 
 Cron takes care of periodic execution of the scripts, but they can be run any
 time directly from /usr/share/btrfs/maintenance/, respecting the configured
 values in /etc/sysconfig/btrfsmaintenance.
 
 If the period is changed manually, the cron symlinks have to be refreshed, use
 systemctl restart btrfsmaintenance-refresh (or the
 rcbtrfsmaintenance-refresh shortcut). Changing the period via yast2 
 sysconfig
 editor triggers the refresh automatically.
 
 The project lives in obs://filesystems/btrfsmaintenance and I'm going to 
 submit
 it to Factory.
 
 I'd like to ask volunteers to give it some testing.  Feedback is welcome.
 
 Thanks,
 David

The package in the opensuse obs:
https://build.opensuse.org/package/show/filesystems/btrfsmaintenance

Seems to mostly consist of shell scripts.

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: btrfs as default filesystem for F22?

[Thorsten Leemhuis]

On 08.10.2014 14:50, Josh Boyer wrote:
 On Wed, Oct 8, 2014 at 1:52 AM, Thorsten Leemhuis fed...@leemhuis.info 
 wrote:
 Josh Boyer wrote on 07.10.2014 21:15:
 On Tue, Oct 7, 2014 at 2:24 PM, Josef Bacik jo...@toxicpanda.com wrote:
 [...]
 http://kernel.opensuse.org/cgit/kernel-source/tree/patches.suse/btrfs--add-allow_unsupported-module-parameter.patch?h=SLE11-SP3
 http://kernel.opensuse.org/cgit/kernel-source/tree/patches.suse/btrfs--add-allow_unsupported-module-parameter.patch?h=SLE12
 [...] 
 I'm not thrilled with adding that patch to Fedora at all. 

Fully agreed.

 […] They get away with this in SLE12 because it's roughly the first time
 btrfs is available in a supported fashion. […]

Well, it's supported since SLE11SP2 already, which is more than two
years old, but the point in the end is the same, yes. But FWIW, it seems
that simply how they work afaics, as they do something similar to ext4, too:

http://kernel.opensuse.org/cgit/kernel-source/tree/patches.suse/ext4-unsupported-features.patch?h=SLE12

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: btrfs as default filesystem for F22?

[Thorsten Leemhuis]

Josh Boyer wrote on 07.10.2014 21:15:
 On Tue, Oct 7, 2014 at 2:24 PM, Josef Bacik jo...@toxicpanda.com wrote:
 […]
 I think the point is somewhat valid though. To just keep repeating the
 mantra 'its not ready' is not going to make it any more ready. If suse
 can identify a stable subset of btrfs features and use it as their
 default file system with those restrictions, why can't we do the same ?
 The approach makes sense to me, at least...
 Because they still have the support staff for when users don't listen,
 Fedora doesn't.
 As an aside, I looked at their 3.16.2-1.1.gdcee397 kernel-source SRPM.
 I can't find any patches that limit btrfs usage.  I could totally be
 wrong, but if someone knows of a patch that limits the features please
 point me to it.

Due to a coincidence I yesterday took a quick look myself and didn't
spot anything. But in case you haven't looked further: I found one in
the SLE-Kernels:

http://kernel.opensuse.org/cgit/kernel-source/tree/patches.suse/btrfs--add-allow_unsupported-module-parameter.patch?h=SLE11-SP3
http://kernel.opensuse.org/cgit/kernel-source/tree/patches.suse/btrfs--add-allow_unsupported-module-parameter.patch?h=SLE12

HTH

CU
knurd

P.S.: BTW, Jeff Mahoney a year ago posted a small table what btrfs
features they considered supported and unsupported:
http://thread.gmane.org/gmane.linux.suse.opensuse.devel/52669/
Is anyone aware of a more current table like that? Or Josef, do the
Btrfs developers maintain one somewhere? I'd welcome one.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Wayland

[Thorsten Leemhuis]

Hi!

Jaroslav Reznik wrote on 29.04.2014 14:04:

 Port the GNOME desktop to Wayland. 

Sorry, but what is actually proposed here? The above sentence for me
doesn't make any sense(¹), as Gnome 3.12 is able to run on Wayland
already (not perfectly, but it works afaik), so it was ported already
I'd say.

Is this about integrating this work in Fedora? Or more porting work? Or
even make Wayland the default in F21? The section How To Test sounds
as if the later is the case, but it's not entirely clear to me.

CU
knurd

(¹) This is not the first change proposal where the summary or the
Detailed Description is more confusing then helpful to me (which makes
me write this mail). It afaics would help a lot if those areas would use
words that ordinary people (think of people that have only basic
computer skills here) would be able to understand.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Wayland

[Thorsten Leemhuis]

Hi!

Jaroslav Reznik wrote on 30.04.2014 16:27:
 - Original Message -
 Jaroslav Reznik wrote on 29.04.2014 14:04:
  Port the GNOME desktop to Wayland.
 
 Sorry, but what is actually proposed here? The above sentence for me
 doesn't make any sense(¹), as Gnome 3.12 is able to run on Wayland
 already (not perfectly, but it works afaik), so it was ported already
 I'd say.
 
 Is this about integrating this work in Fedora? Or more porting work? Or
 even make Wayland the default in F21? The section How To Test sounds
 as if the later is the case, but it's not entirely clear to me.

 (¹) This is not the first change proposal where the summary or the
 Detailed Description is more confusing then helpful to me (which makes
 me write this mail). It afaics would help a lot if those areas would use
 words that ordinary people (think of people that have only basic
 computer skills here) would be able to understand.
 
 I usually try to work with change owners on clear wording,

I know. Many thanks for all your hard work.

 […]

 For wording - Changes are *not* supposed to be read by general public,

But we know the public reads them, as those that write websites, blogs
and sometimes even magazines articles will pick these things up --
especially in cases like this. Unclear words or statements thus could
lead to confusion or bad press.

Side note: If you can't explain it simply, you don't understand it well
enough.

 it's internal planning tool and docs/marketing guys makes it consumable
 in the end.

Thus FESCo, ordinary developers like me (we get these change propose
mails for a reason) and docs/marketing should be able to properly
understand it -- which afaics to often is not the case :-/

 But generally I agree - better wording, better understanding.

+1

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

[Thorsten Leemhuis]

Hi!

On 23.01.2014 19:26, Josh Boyer wrote:
 On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis fed...@leemhuis.info 
 wrote:
 
 […]

Thx for your answer, just replying to some parts of it where I feel that
making additional statements bring the discussion forward.

 What really gives me the creeps on those pages: sub-committees of
 FESCo, with individual governance structures. Those afaics are three
 Product Working Groups Workgroups, two Fedora Rings Working Groups and
 the Inter-WG for coordination. That sounds like a awful lot of
 overhead an even more bureaucracy than we already have. And we imho
 have way to much already (part of it is my fault!) – something I had
 hoped Fedora.next would try to fix.
 It is more overhead to a degree.  On the other hand, the idea is to
 enable people that are interested in specific areas to go forth and
 create a Fedora deliverable that they think meets the needs of those
 areas best, without having to pass everything through FESCo.  FESCo
 just doesn't scale like that.

Sure, but I doubt that more committees are the best way to solve that.
I'm wondering if a development approach that more resembles the Linux
kernel would be better. Sure, the kernel also has people (not
committees!) that steer things and some rules (a lot not written down,
which has benefits imo). And in the end it's a lot if you want
something crazy new realized you can do that as long as you do not break
the things others care about. More of that attitude and less
rules/committees is something I'd like to see in Fedora.

 I these days wouldn't start contributing to Fedora, as all those rules
 and guidelines that the wiki provides would scare me off. That's what
 Fedora.next should fix imo, as we afaics need more contributors: I
 more often than a few years ago find packages in Fedora that are badly
 maintained or outdated. Contributing must be as easy as editing a
 The packaging guidelines are very daunting.  Automating as much of
 that as possible, either through spec creation tooling or package
 review tooling would help.

I think it's not only the packaging guidelines imho, it's the whole
processes around package maintenance -- for existing packagers and
newcomers.

I for example recently saw that a package I used to maintain long ago
was outdated in fedora 20. I chose to ignore it in the end, as I didn't
want to nag the current maintainers via bugzilla (yes, I should have
done that; sorry, was overly careful or lazy, but that's how people are
quite often afaics); I would have preferred to simply do a fedpkg clone
foo; update, build, quick test run and then submit it to rawhide,
without fearing somebody might yell at me(¹). IOW: like editing a
wikipedia page, even if that's in the end more work that simply filing a
bug.

(¹) Yes, I still have provenpackager rights, so I could have done that,
but that wouldn't be considered appropriate under current rules

 wikipedia page. Further: kororaproject.org, fedorautils-installer and
 similar project show that there are people that want to make Fedora
 better. But they do their work outside of Fedora and RPM Fusion;
 fixing the issues directly at the root would be better for all of us.
 Small note:  The two projects you use as an example are required to do
 what they're doing (in part) outside of Fedora for legal reasons.  I
 don't believe Fedora.next will change how US law works, so it might
 not be the best of examples.

Hmmm. Maybe it were bad examples. But I guess I didn't actually explain
the point I was trying to make properly. So here we go in different
words after a few more quotes lines:

 (And we have a Board meeting to discuss related things that are not
 legally prohibited.)
(for the archives: see
https://lists.fedoraproject.org/pipermail/advisory-board/2014-January/012433.html
for context and outcome; in short: the Fedora board voted against the
proposal to allow 3rd party repos in the App installer)

The Fedoraproject once again chose to leave non-free out of Fedora. I
appreciate that. I even think a lot of users understand why the
Fedoraproject acts like this (now and earlier, too). But: it utterly
hard to get non-free Software when running Fedora. That's what the
Fedora ecosystem IMHO needs to fix. Debian, who has a similar stance on
non-free Software, does a way better job in that area than Fedora does.
We need to catch up here and I think the Fedoraproject should drive
this, because it's important for the success of Fedora (and RHEL/CentOS)
that people can easily use it for what they want. And as the down-voted
proposal shows: There are developers within the Fedoraproject that are
willing to do the work; there are more in Korora, RPM Fusion and other
places. We just need to bring them together properly afiacs.

Obviously those developers need a place to do their work. I think RPM
Fusion is that, as it's well established and something a lot of people
all to Fedora anyway. But yes, RPM Fusion contains packages that are
problematic under

Re: Fedora.next in 2014 -- Big Picture and Themes

[Thorsten Leemhuis]

Hi!

On 23.01.2014 20:57, Matthew Miller wrote:
 On Thu, Jan 23, 2014 at 07:03:02PM +0100, Thorsten Leemhuis wrote:
 Okay, I'll bite (after thinking whether writing this mail is worth it):
 Thanks. I hope that I can make you feel that it was.

Thx for your answer – yes, I think it was worth it. But I hope I don't
get a Fedora badge that says started a discussion in
devel@fedoraproject that made it to Phoronix ;-)

 [...]
 I will be giving a talk on Sunday, February 9th in at DevConf in Brno, CZ,
 and I'll post slides from that (probably here as text as well), and I assume
 there will be video. 

That's great (I'll be there; Fosdem as well), but please allow me a side
note here: Videos and IRC logs are a great resource if you really care
about something and want to know all the details. But the ratio for
time spend watching/reading vs. information gathered is often quite
bad. That's why written, easy to read summaries are important. And I
think we got too few of them from Flock last year, which is one of the
reason why I had/have problems to fully understand Fedora.next.

 [...] 
 But also, I want to go back to the first part of my message that you're
 responding to. I don't think our current online communication structure
 really works very well for the kind of contributor you're concerned about.
 (Let alone working very well for more active contributors who still don't
 have time to read every list or hang out on IRC 24/7.) I think we need to
 fix that, whether we consider that part of Fedora.next or a separate big
 initiative.

Agreed. For example, +1/like-Buttons for a mailing list would be good
afaics, to get a rough impression how people think (just wondering: will
hyperkitty or something from that camp of developers have this?). But
that's just one thing that springs to my mind and a different topic.

In addition: A few days ago someone shared the article Top 10 ways to
ensure your best people will quit on G+:
http://www.ragan.com/Main/Articles/Top_10_ways_to_ensure_your_best_people_will_quit_47779.aspx
I normally don't read or like things like that much, but I enjoyed this
one. And I wondered if all of those points are relevant for Fedora as
well. I tend to think they are. Point 3 for example made me wonder if
every few months we should ask developers if they are happy with the
current state and how things evolve. Obviously automated web based
questioning system or something like that. Something simple could do for
the start. That way we could get early warning signs if developers are
unhappy, to do something before they leave.

 I have many more thoughts in my head, but I'll stop here, as those are
 basically the most important things that bother me right now when
 looking at Fedora and Fedora.next.
 I appreciate it. Does anything I've said help you feel better about it? 

To be honest: only a little bit. Fedora.next simply is so big (I'm
wondering if too much is cramped into it) and still vague in some parts
that I remain careful. But that's not unusual, I'm quite sceptic all the
time and more of a pessimist ;-)

 [...]
 I would like to hear more of your thoughts, too.

In the past few months a few people encouraged be to write down how I'd
design Fedora if I could. Maybe I should finally do that – but OTOH I'm
not sure if that is worth the work and if it's really helpful for the
curent debate.

And for now I have something else I need to take care of first:
preparing my devconf talk :D

Cu  have a nice weekend everyone
 knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

[Thorsten Leemhuis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi!

On 23.01.2014 22:33, Kevin Fenzi wrote:
 On Thu, 23 Jan 2014 19:03:02 +0100 Thorsten Leemhuis
 fed...@leemhuis.info wrote:
 On 03.01.2014 19:14, Matthew Miller wrote:
 […] So those are my things. What do you think about them? What 
 else should be included? What different directions should we 
 consider? How will we make Fedora more awesome than ever in
 the coming year?
 Okay, I'll bite (after thinking whether writing this mail is
 worth it):
 Hey Thorsten! Glad you did. ;)

:)

 I'm still undecided if I overall like Fedora.next or fear it. But
 more and more I tend to the latter position and wonder if it
 might be wise to slow things down: Do one more Fedora release the
 old style in round about June; that would give us more time to
 better discuss and work out Fedora.next and get contributors
 involved better in the planing.
 This is not practical. Lots of people are thinking about a 
 fedora.next, qa folks are coding away, lots of people who normally 
 would be working on the next release are not. If we tell them to
 stop all that and go back to normal, we could, but then fedora.next
 will likely never ever happen.

Understood, but OTOH it makes me wonder if Fedora.next is a step to
big and needs to be split or something.

 [...] The current problem I have with Fedora.next is that it's so
 abstract. I understand that people who like PRD's and TPS want high
 level descriptions of what we want to do with goals and visions and
 such, and thats great. However, I'm a technical person. I like
 concrete plans and pushing what we can do with the technology we
 have at hand, or helping to make new technology to do what we want.
 
+1 you found really good words for what's a big part of the problem I
have with Fedora.next

 We are now down to the point where groups have written up their
 PRD documents, and can get down to details. So, I am hopeful in the
 next month or so we will gain a lot more interest in fedora.next
 and more feedback as concrete deliverables are discussed, etc.
 
 That is my hope at least... we will see. :)

Yeah, we'll see :D

Your words otoh scratched another thought in my head: The PRD
documents (and some of the other docs around Fedora.next) in great
length talk a lot about how they want to do something. That up to a
point is needed obviously. But sometimes I miss a few introductions
words on the why we want all of that and how it's supposed to make
Fedora better. But that's obviously meta/abstract again, which I
myself criticized earlier. So maybe it's simply this ted talk that
stuck in my head too much:
http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

Cu
knurd
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJS46KJAAoJEHK25u9MWD0tf8oQAKamRcqVt8XTbh8TmjfWxqqc
AeP5MVmJnhE9TEbgsenZUex0xo3dnRaU9prdF/delAVgL7ahCbIPWgKtKT3IsqsA
GHygf8d046PM2+z8lFH8IAinK5KhikmRki/xS+3IknHEPWUKmGcFtIG13L2C32w/
VEZ+/IF70NEa2xe7jtg0QzH4uungZfVH6Gsl2WcsjnjC0BiqU5vkVjdDWKWCt+GD
taAL5pNbO1TsuAhnNa4PL/eHJehEGUo1UrLv4FDnPFLm4v6Wex9VScd6Z2XQ6VLu
I2Lw5RqU5m0kNPa5k4+gEABqDrqObK6Q+akwX/c97Tcus52SwmIQA4yHGHsIQy2c
hSeg/mQyzZHabob909EPu2y6/m49uEpmU8sgb7QqQzIk77rKaUQrGloPSOTrAs6j
TSMtZX/DkF6VZIBATSTtOJD7pL3jvCWOb66ueA+MJqGZdB3WiuB7En+9JTrhjYSe
mEs9KORkYgyQniVTlhtVG9tu8/OFvt8ud+iq+FlAVzyHAfDofpC+w7WnkSSn3Mit
wEEgsvuYx630z+HY2+aBBViU+/11D1G8lVBJqGINogPRxopTpN9EPCbvAOnHmwd3
iOqsPzsUjZCviXasjIrrj91QDXduS/N3sFCam1dq2CqXF692ampEzAfavu/VX9yB
jfSdBXA1/7Vk/MLXgB6E
=BoBF
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

[Thorsten Leemhuis]

Hi!

On 23.01.2014 22:45, Adam Williamson wrote:
 On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote:
 
 wikipedia page. Further: kororaproject.org, fedorautils-installer and
 similar project show that there are people that want to make Fedora
 better. But they do their work outside of Fedora and RPM Fusion;
 fixing the issues directly at the root would be better for all of us.
 Those particular examples are very bad examples because they are doing
 things Fedora explicitly chooses not to do, [...]

See my reply in
https://lists.fedoraproject.org/pipermail/devel/2014-January/194581.html
as that hopefully better explains what I had up in my mind.

 [...]
 And the lead Korora dev is an active Fedora contributor.

I know, but for me Korora, fedorautils-installer, and similar things are
a sign that some problems in Fedora and RPM Fusion get circumvented in
to many layers instead of being solved at their root. It reminds me of a
kernel enhancement that is maintained outside of the Linux kernel: they
often solve real problems and some users love them, but it's better for
everyone to get a proper solution upstream, as that's the way to reach
the masses and make things simply work.

Cu
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

[Thorsten Leemhuis]

On 25.01.2014 17:35, Adam Williamson wrote:
 On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote:
 
 Debian, who has a similar stance on
 non-free Software, does a way better job in that area than Fedora does.
 Well, not really - they don't have a 'similar stance', they have an
 official non-free repository. That's kind of a significant
 difference. :)

Ha, Debian and Fedora, the distributions, are imo not that different
after a standard install (but yes, there are differences as well -
patents strategy, Firmware). But yes, you are right, the Debian project
has a a official non-free repository, which is a significant difference
to the Fedora project. One that leads to a better user experience;
something that afics a lot of Fedora users and some Fedoraproject
developers want to see as well. That's why I think it would be good if
the the Fedora project might help/guide in that are, even if the
resulting repo and the main work is done outside of the Fedora project.

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

[Thorsten Leemhuis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi!

On 03.01.2014 19:14, Matthew Miller wrote:
 […] So those are my things. What do you think about them? What
 else should be included? What different directions should we
 consider? How will we make Fedora more awesome than ever in the
 coming year?

Okay, I'll bite (after thinking whether writing this mail is worth it):

I'm still undecided if I overall like Fedora.next or fear it. But more
and more I tend to the latter position and wonder if it might be wise
to slow things down: Do one more Fedora release the old style in round
about June; that would give us more time to better discuss and work
out Fedora.next and get contributors involved better in the planing.

The main reason for that: Fedora.next is a huge effort that seems to
make everything even more complicated. It imho is also sold pretty
badly right now, as you have to invest quite a lot of time to
understand what Fedora.next actually is. And Fedora.next to me seems
like something the core contributors push forward without having
really abort those Fedora contributors who don't have Fedora as one of
their top priorities in life.


Verbose: Yes, I really think the Fedora needs changes -- at some point
a few years ago we mostly continued to do things as they have always
 been done (read: since Core and Extras merged), without thinking if
those ways are still the best.

So I welcomed Fedora.next in the beginning. But I, as someone that is
not involved very much in Fedora any more, still fail to fully grasp
it. Yes, there are many mailing list or blog posts and some docs in
the wiki. But most of them are really way too long for people that
have busy days; a lot of those docs are also quite meta,
nevertheless afaics failing to give a goal. Take
https://fedoraproject.org/wiki/Fedora.next for example. It more a
description of a vague idea without saying much concrete besides
design, build, and market three distinct Fedora products (what is a
Fedora product?). There are a few links there, but even
https://fedoraproject.org/wiki/Fedora.next/boardproposal is still
quite meta for something which is supposed to be the base for a
release that is eight months or so away. It doesn't explain what
problems are being solved or what happens to spins (KDE and such) or
how often (according to current plans) Fedora will be released in the
future.

What really gives me the creeps on those pages: sub-committees of
FESCo, with individual governance structures. Those afaics are three
Product Working Groups Workgroups, two Fedora Rings Working Groups and
the Inter-WG for coordination. That sounds like a awful lot of
overhead an even more bureaucracy than we already have. And we imho
have way to much already (part of it is my fault!) – something I had
hoped Fedora.next would try to fix.

I these days wouldn't start contributing to Fedora, as all those rules
and guidelines that the wiki provides would scare me off. That's what
Fedora.next should fix imo, as we afaics need more contributors: I
more often than a few years ago find packages in Fedora that are badly
maintained or outdated. Contributing must be as easy as editing a
wikipedia page. Further: kororaproject.org, fedorautils-installer and
similar project show that there are people that want to make Fedora
better. But they do their work outside of Fedora and RPM Fusion;
fixing the issues directly at the root would be better for all of us.

And I really wonder if Fedora.next is really backed by those community
contributors that are not involved in Fedora to deeply. One reason for
that: Fedora.next mails like the one I'm replying to seem to get very
few responses -- especially considering the fact that Fedora.next is
something really important and brought to a list where small details
quite often spawn very long discussions. Sometimes it's different --
like the ongoing and long 3rd party and non-free software
discussion. That shows that a lot of people still care, but don't
bother follow to closely what the workgroups discuss before it someone
gets to a point where it's more visible.

That's why I got the feeing a lot of contributors are simply waiting
for more concrete details to emerge before deciding what to make of
Fedora.next; or they simply at all don't care to much what the higher
ups do, as getting involved on that level can cost quite a lot of time
and can be frustrating (that's not a complaint, that's simply how it
is often; wasn't much different in my days, but noticed that more when
I wasn't that active an more myself).

I have many more thoughts in my head, but I'll stop here, as those are
basically the most important things that bother me right now when
looking at Fedora and Fedora.next.

CU
knurd

P.S.: Fixed subject (s/2013/2014/)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJS4VlWAAoJEHK25u9MWD0tjR0QAJAe7Z35vN90Moq1mXGRpiMJ

Re: ntfs-3g critpath update for F18 needs karma

[Thorsten Leemhuis]

On 18.02.2013 16:26, Richard W.M. Jones wrote:
 
 https://admin.fedoraproject.org/updates/FEDORA-2013-1536/testdisk-6.13-5.fc18.1,ntfs-3g-2013.1.13-1.fc18.1
 
 This update needs karma.  Apparently I can't push it otherwise, even
 though it works fine for me.
 
 Note that there are two -1's on that which apply to older versions
 of testdisk, since fixed so those don't apply any more. 

Provided positive karma a few minutes ago, problem solved afaics.

 (Who is thl?)

Me, one of the contributors from the early Fedora days (argh, just
noticed, that was nearly ten years ago; will we have a party in
September?) that many many years ago switched from thl to knurd nearly
everywhere, but never bothered to change it in fas ;-)

Cu
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Kernel 3.7 in Fedora 18

[Thorsten Leemhuis]

On 27.12.2012 10:34, M.M. wrote:
 Is kernel 3.7 expected to be available for Fedora 18?
 If so, can you estimate how long it will take?
 Thank you.

See http://jwboyer.livejournal.com/46002.html
Quoting one part:


 Fedora 18: […] The 3.7 kernel rebase will be available as an update via the 
 normal update mechanisms shortly after release.


You can give it a try already:

 * Justin has 3.7.1 in his rawhide-nodebug repository:
http://jforbes.livejournal.com/13295.html

 * I have 3.7 vanilla in my kernel vanilla mainline repos (I didn't get
around updating to 3.7.1 yet and putting it in the stable repos):
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories

See also: http://jwboyer.livejournal.com/45269.html

HTH

CU
knurd


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PSA: updates-testing default disabled now

[Thorsten Leemhuis]

Hi!

On 21.12H.2012 18:34, Kevin Fenzi wrote:
 Just a heads up to everyone using f18 right now: 
 
 with fedora-release-18-1 that just pushed out to updates-testing
 yesterday, the updates-testing repo is now by default disabled. 
 [...]

I for one find it annoying having to fiddle with the repo files every
few months to make sure testing stays enabled (which I and likely others
often forgot, which is not what Fedora wants). Yeah, it's just a small
and IMO slightly confusing detail, but those small annoying details can
add up and make people unhappy, I'd say.

Hence the question: isn't there a easy way to avoid this somehow in the
future? Could bodhi maybe modified to simply push everything straight to
the unused updates repo instead of updates-testing while a distro is
still under heavy development (e.g. up to this point for F18)? Yes, I
know, the behaviour would be different then from a updates repo for a
stable release, but it's a distro under development anyway and hence
different rules apply in any case.

Cu
knurd


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg / koji error

[Thorsten Leemhuis]

Lo!

On 23.10.2012 17:23, Tom Callaway wrote:

On 10/22/2012 10:37 PM, Ralf Corsepius wrote:

On 10/22/2012 10:43 PM, Tom Callaway wrote:

On 10/22/2012 12:09 PM, Ralf Corsepius wrote:

There is currently no way to undefine a macro at the rpm commandline,


rpmbuild --define  %{nil} ?


Huh, I swear I knew that once. :) Attached is a patch to use the %{nil}
behavior instead of setting the unused dist macro to 0. I smoke tested
and confirmed that the %{rhel} macro is unset on Fedora with this patch
applied.


I haven't tried your patch, but don't you have to unset/define %{nil}
all build-host related rpm macros from /etc/rpm/macros.dist?

It's at least what I can not avoid doing in my before-mentioned
build-scripts.

I.e. when running my script on Fedora 17, I invoke rpmbuild this way:

rpmbuild ... \
  --define fedora %{nil} --define fc17 %{nil}
  --define dist .el6 --define rhel 6  --define el6 1
  ...

Otherwise constructs such as
%{?fc17:}
%{?el6:}
also won't work correctly in rpm.specs.

IIUC, fedpkg with your patch sets %dist and unsets %fedora, but it
doesn't seem to catch fc17.


Yeah, thats a valid corner case. It wasn't in the original issue, so I
didn't think about it. I'll work on a fix that covers that as well.


Spot: Thanks for working on this and finding a solution that removes the 
inconsistency I was running into with someone else package.


Ralf: Thanks for the idea with the %{nil}

CU
knurd
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Wayland update broke mesa?

[Thorsten Leemhuis]

On 19.10.2012 16:10, Jerry James wrote:
 I'm working my way through Rawhide rebuilds for the recent OCaml
 update.  One of my builds failed last night like this:
 […]
 File ide/coqide_main.ml4, line 1:
 Error: Error on dynamically loaded library:
 /usr/lib/ocaml/stublibs/dlllablgtk2.so: /lib/libEGL.so.1: undefined
 symbol: wl_display_sync
 make[1]: *** [bin/coqide.byte] Error 2
 make[1]: Leaving directory `/builddir/build/BUILD/coq-8.4'
 make: *** [world] Error 2
 
 
 There was a new build of wayland last night, which is where
 wl_display_sync used to be defined.  I don't know enough about either
 mesa or wayland to know what the proper solution is, but it looks like
 libEGL is currently broken in Rawhide.

I'd assume mesa in Fedora needs this three patches:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=0229e3ae41be109ac423b2eb2ddf79e24b799d60
http://cgit.freedesktop.org/mesa/mesa/commit/?id=2b8e90a33826dcd30b0cbbf464fbd191bf299d38
http://cgit.freedesktop.org/mesa/mesa/commit/?id=e20a0f14b5fdbff9afa5d0d6ee35de8728f6a200

Background:
http://lists.freedesktop.org/archives/wayland-devel/2012-October/005740.html

HTH

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Wayland update broke mesa?

[Thorsten Leemhuis]

On 19.10.2012 22:54, Thorsten Leemhuis wrote:

 I'd assume mesa in Fedora needs this three patches:
 
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=0229e3ae41be109ac423b2eb2ddf79e24b799d60
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=2b8e90a33826dcd30b0cbbf464fbd191bf299d38
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=e20a0f14b5fdbff9afa5d0d6ee35de8728f6a200
 
 Background:
 http://lists.freedesktop.org/archives/wayland-devel/2012-October/005740.html

Ajax added the needed patches to Fedora's mesa pkg a few hours ago
already, so everything should be fixed soon afaics:
http://pkgs.fedoraproject.org/cgit/mesa.git/log/

Sorry, I had opened above page to check that before writing my last
mail, but then forgot to look at it properly :-/

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg / koji error

[Thorsten Leemhuis]

Lo!

On 09.10.2012 20:03, Jesse Keating wrote:
 On 10/09/2012 07:14 AM, Simone Caronni wrote:
 On 19 September 2012 00:26, Orion Poplawski or...@cora.nwra.com wrote:
 On 09/05/2012 08:07 PM, Tom Callaway wrote:
 Jesse, I'm not sure if you're still the correct upstream here, please
 correct me if you're not, and I'll send the patch somewhere else.
 This helps me a lot as well building el srpms from master with fedpkg
 --dist el6 srpm.  +1 from me.
 Any news regarding this? Is the patch planned to be included?
 I don't see any activity in git: http://git.fedorahosted.org/cgit/fedpkg.git/
 Oops.  I dropped the ball.  Spot even pinged me about it and I made a 
 promise I didn't keep.  Rectifying.

Patch was integrated and a updated fedpkg is in updates-testing
currently -- which leads to wayland support in mesa.spec being not build
when you build it with fedpkg, as it contains this %configure statement:

 --with-egl-platforms=x11,drm%{!?rhel:,wayland} \

The ,wayland is not added, as rhel is defined now as 0 when building
with fedpgk. If you build a srpm and try to build it with rpmbuild then
it works, as it's not defined there. I explained it in more detail in
https://bugzilla.redhat.com/show_bug.cgi?id=867375 , which made me
brining up the issue here, as Jesse was unsure how to proceed.

I'd say the current behaviour is the quite bad, as it leads to different
results when building with fedpkg and rpmbuild on F18. The real fix
afaics would be to revert the change and, if wanted, define rhel as 0 in
Fedora's redhat-rpm-config, too -- but then we obviously need to fix all
%{!?rhel:foo} statements in current spec files.

Options? Spot, Simone?

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg / koji error

[Thorsten Leemhuis]

On 18.10.2012 10:45, Simone Caronni wrote:
 On 18 October 2012 09:57, Thorsten Leemhuis fed...@leemhuis.info
 mailto:fed...@leemhuis.info wrote:
  --with-egl-platforms=x11,drm%{!?rhel:,wayland} \
 The ,wayland is not added, as rhel is defined now as 0 when building
 with fedpgk. If you build a srpm and try to build it with rpmbuild then
 it works, as it's not defined there. I explained it in more detail in
 https://bugzilla.redhat.com/show_bug.cgi?id=867375 , which made me
 brining up the issue here, as Jesse was unsure how to proceed.
 Can't you

Just for completeness: Mesa isn't my package. I just build a modified
version locally when I ran into trouble that lead to the bug I mentioned.

 check that rhel is not defined and different than 0?

That's obviously possible.

 The packaging guidelines say that a 0 should be used when checking for
 conditions:

But sometimes people do things wrong :-/ If we define rhel as 0 in
redhat-rpm-config then people will notice this case immediately themselves.

 With the old one I had to check like this (first line) for building;
 which is not correct anyway as the behaviour was different as well
 between fedpkg and rpmbuild/mock: [...]

And that should not be the case imho. But if we define rhel as 0 in
redhat-rpm-config instead (or in addition?) of fedpgk, then your case
should remain fixed as well -- or am I missing something?

Cu
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox / Thunderbird 17 ESR for Fedora 16/17

[Thorsten Leemhuis]

On 22.09.2012 13:02, Julian Sikorski wrote:
 W dniu 21.09.2012 15:33, Martin Stransky pisze:
 as the subject says there are test packages available for your beloved
 Fedora's. Especially Thunderbird 17 (Earlybird now) needs some love from
 you (the 17ESR line is going to be a background for the future ones) so
 it would be great if you can install it, run it and report any issues.
 All instructions are at:

 https://fedoraproject.org/wiki/Firefox

 NOTE: All those packages are pre-release and are targeted to experienced
 users!

 Does it mean Fedora will stop shipping the latest FF/TB and stick to ESR
 instead? Or is it for parallel-installation purposes?

Unlikely and IMHO unwanted (at least from my side) afacis, as other
answers already indicated. But that is not the reason for this mail.
This is:

Has anybody considered to package the ESR releases for Fedora or is the
general consensus that doesn't make much sense, just leads to confusion
and is not worth the trouble. I now and then could need a parallel
installed Firefox ESR for a Webinterface that officially only supports
ESR releases. I can simply install one in my homedir, but it would be
nice to have it yum-installable from the stock Fedora repos (but the
problem does not bug me enough to submit a package myself).

Cu
knurd

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox / Thunderbird 17 ESR for Fedora 16/17

[Thorsten Leemhuis]

On 23.09.2012 13:10, Reindl Harald wrote:
 Am 23.09.2012 13:06, schrieb Thorsten Leemhuis:
 Has anybody considered to package the ESR releases for Fedora or is the
 general consensus that doesn't make much sense, just leads to confusion
 and is not worth the trouble. I now and then could need a parallel
 installed Firefox ESR for a Webinterface that officially only supports
 ESR releases. I can simply install one in my homedir, but it would be
 nice to have it yum-installable from the stock Fedora repos (but the
 problem does not bug me enough to submit a package myself).
 you can not have BOTH in the repos in a way that
 the installation doses not conflict and you are
 missing that switch between both will bring
 you problems with your profile

Something like that, yeah.

 YOU may be able to work around them with seperated profiles
 99 out of 100 users are not and would damage their data

All that software that is involved is open-source, hence solutions or
workarounds for today's problems could be developed if someone thinks it
is worth the trouble.

 what is this for webinterface only supporting ESR?
 why in the world should a WEBPAGE not work with a NEWER firefox?

It's not so much about work, more about support, because for a
software vendor it's risky if you are telling your customers that your
software is supporting browsers that are not made yet ;-) Even
supporting state of the art browsers is sometimes something software
companies fail to achieve. Look here for example:

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1-Beta/html-single/Administration_Guide/index.html#Jasper_reports_system_requirements

Quoting:

The Red Hat Enterprise Virtualization Manager Reports tool supports the
following browsers:

In Red Hat Enterprise Linux 5.7 - Firefox 3.6

In Red Hat Enterprise Linux 6 - Firefox 3.6


IOW: If you want it or not, you sometimes need older browsers if you
want to run a supported configuration (the example is bad because here
one even needs a old, EOLed browser and not a Firefox ESR that's still
supported; but you get the idea).

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 3.5 overheating - temperature increase of 83%?

[Thorsten Leemhuis]

Michał Piotrowski wrote on 06.08.2012 08:59:
 
 I noticed some strange sensors values on Linux 3.5
 [...]
 Do anyone else noticed something like that?

I'd say this post is off-topic here and this (and all further replies)
should have gone/should go to this list instead:
https://admin.fedoraproject.org/mailman/listinfo/users

But maybe I'm overly strict here; otoh maybe I shouldn't even answer at
all here. Nevertheless: Is that an Atom? If yes than I'm dare to do a
wild guess: It *might* be normal and resulting from these changes that
went into 3.5:

http://git.kernel.org/linus/41e58a1f2b90c88d94b4bd84beb9927a4c2704e9
http://git.kernel.org/linus/fcc14ac1a86931f38da047cf8fb634c6db7b58bc
http://git.kernel.org/linus/5592906f8b01282ea3c2acaf641fd067ad4bb3dc

HTH

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Booting Fedora from LVM with grub2

[Thorsten Leemhuis]

Adam Williamson wrote on 27.03.2012 20:14:
 [...]
 It's worth bearing in mind there's a giant anaconda UI rewrite still
 pending, which entirely redesigns the storage configuration GUI. One of
 the other major changes is that it makes all installations
 kickstart-driven. The GUI will just produce a kickstart file, which
 anaconda will then process to perform the actual install.

Just out of curiosity: Your description makes me assume that the
installer in the future still don't do things like partitioning,
formating or installing a basic set of packages in the background while
the user (which has a high latency/response time) is asked questions
about the root password to use, users accounts to create or which
timezone the system is in?

Just wondering, because the Ubuntu installer does things like that,
which makes the installation a little bit quicker.

CU
 knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary minutes for today's FESCo meeting (2012-03-19)

[Thorsten Leemhuis]

Josh Boyer wrote on 20.03.2012 02:26:
 On Mon, Mar 19, 2012 at 3:46 PM, Jon Ciesla limburg...@gmail.com wrote:
 * #830 F18 Feature: ARM as Primary Arch --
  https://fedoraproject.org/wiki/Features/FedoraARM  (limburgher,
  18:44:13)
  * LINK:

 http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
(nirik, 18:45:42)
  * AGREED: ask qa, rel-eng, kernel and infra teams to provide feedback
on the proposal. Ask fesco members to come up with critera that they
would want to add and revisit next week.  (+8,-:0,0:0)  (limburgher,
19:09:50)
 
 It's fairly disappointing this was discussed during this meeting without
 being on the agenda that was sent out.  This is a rather large item that
 needs a lot of discussion among the various groups in Fedora, and I'm sure
 that I'm not the only person that wasn't aware it was even going to be in
 the meeting today.  (Even ignoring the fact that the agenda was sent without
 a proper Subject and easily skipped.)

+1

From my point of view the root of the problem is: Crucial information is
spread over way to many places which makes it hard to stay on top. If
you want to be aware of what happens in Fedora land, that you afaics
have to keep an eye on

- this list and at least fab-list
- parts of the wiki, which is really hard (for example there is afaics
no easy way to just follow the pages that are used to track new Features )
- the talk pages to those wiki pages (see yesterdays discussion about
the proposed kernel-module, where I missed to look there)
- the tickets in trac (like the one for Fesco meetings)
- and ideally IRC and some more lists

I have no real idea how to fix this, but I tend to say we need to way
better make sure that important information and discussion get on this
list in a easy consumable way(¹), as that's the only place where
everybody looks. Sure, that can lead to a heated discussion, but then
let's deal with it.

CU
 knurd

(¹) it for example always annoys me a little bit that there are no
direct links to the trac tickets in which FESCo tracks the issues it
wants to discuss in a meeting -- I know how to find them and it's just
one or two additional clicks, but those are a little bit annoying
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Draft schedule for tomorrow's FESCo meeting (19 March 2012)

[Thorsten Leemhuis]

Hi!

/me gave the mail a subject

Jon Ciesla wrote on 18.03.2012 23:33:

 = New business =
 [...] 
 
 #topic #822 F18 Feature: AE1000 USB wifi driver -
 https://fedoraproject.org/wiki/Features/AE1000usb
 .fesco 822

I must be missing something here. Is that a early April fools joke or is
that simply a feature where the Feature owner (and apparently nobody
else) first asked for advise on this list and on
ker...@lists.fedoraproject.org. If he did it I missed that, which is
possible, but I'd assume he would have quickly been told that Fedora
normally(¹) doesn't do things like that (e.g. include kernel drivers
that are not in the upstream kernel).

CU
knurd

(¹) yes, there are exceptions, but I doubt one will be given here
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Clarify our position on forks (was: Re: Plan for tomorrow's FESCo meeting (2012-02-27 at 18UTC))

[Thorsten Leemhuis]

Kevin Fenzi wrote on 27.02.2012 04:21:
 
 #topic #810 Clarify our position on forks .fesco 810

It's just a statement that is asked for in the ticket, but nevertheless:
Shouldn't issues like this be discussed on this list first, so FESCo
members can get a impression from the flamewar ^w discussion what the
developer community thinks about the issue raised?

CU
 knurd

P.S.: For those that are to lazy to click two times (I assume a lot
people are to lazy; I'm often to lazy myself...) to open the ticket in
question, here is its text:

 phenomenon
 
 We have a policy to  forbid bundled libraries, but it's unclear what
 this means for forks. background analysis
 
 With mate and cinnamon, forks seem to become more and more popular.
 Some of these forks are about to enter Fedora and therefor we need to
 clarify our position on forks and the duplication of system
 libraries.
 
 Both muffin (fork of mutter) and cinnamon (fork of gnome-shell) are
 forks for nearly a reason. The code changes are minimal, the biggest
 change is the change of the headers to include the new FSFE address -
 and it seems not even this trivial change was forwarded to the GNOME
 developers.
 
 There are more problems:
 
 We are already working around problems in packaging that were fixed
 in the orignal code upstream Given the rate of commits the forks will
 have a hard time catching up with the originals. They already lag
 behind massively.
 
 More background info in Bugzilla
 
 https://bugzilla.redhat.com/show_bug.cgi?id=771252 in particular
 https://bugzilla.redhat.com/show_bug.cgi?id=771252#c21
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 ext4 discard option - why not default?

[Thorsten Leemhuis]

On 16.03.2011 18:55, Ric Wheeler wrote:
 On 03/16/2011 01:53 PM, Michał Piotrowski wrote:
 I installed F15 on SSD and I noticed that file systems are not mounted
 with discard option.
 Shouldn't discard option be enabled by default for SSD devices?
 
 No - discard is off on purpose. Some SSD's work very well, others have 
 performance issues with discard and some even became unusable bricks.
 
 The idea is to have it off by default so people can test. Over time, if 
 things 
 go well, we can think about changing the default.

That IOW and AFAICS means that we need a whitelist or a blacklist (or
both) in the long term anyway, as those that become bricks won't simply
vanish over night.

So why not start with that now? Or is the answer simply a lack of
resources/people interested to drive things forward?

Just curious. I have a Intel SSDSA2M080G2GC for a while now but was not
bold enough yet to give discard on Ext4 a try.

Cu
 knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: i686/x86_64 dual install media

[Thorsten Leemhuis]

On 25.10.2010 20:49, Adam Williamson wrote:
 On Sun, 2010-10-24 at 10:45 -0400, Mark Bidewell wrote:
 Sorry if this has been discussed, but has there every been discussion
 of a dual 32/64-bit install media?  I realize that the default package
 selection would be reduced but with a high speed connection it
 shouldn't be too big of an issue.  Having a single ISO for both my
 64-bit desktop and 32-bit laptop would be quite nice.
 
 It wouldn't make sense to make everyone download the default package set
 twice, when only a relatively small amount of people actually need to,
 and the extra work involved in downloading and burning two separate ISOs
 is so tiny.

But a combo x86-32/x86-64 install media OTOH would be very interesting
for magazines that want to ship Fedora on a enclosed DVD, as that's
cheaper than two and makes way more readers happy than a x86-32 only
DVD. Ohh, and a combo install media might be interesting as hand out for
fairs and conferences, too.

Just my 2¢.

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: xulrunner 2.0 in rawhide (F15) bundles several system libs

[Thorsten Leemhuis]

Kevin Kofler wrote on 14.10.2010 00:36:
 Thorsten Leemhuis wrote:
  * Why haven't those that want iceweasel and icedove in Fedora not
 simply invested some time and got them integrated into the repository?(¹)
 Because having both Iceweasel and Firefox in the repository, in addition to 
 being stupid by itself, would also mean shipping 2 different versions of 
 xulrunner (because there's where most of the offending patches live).

If you run a 's/, in addition to being stupid by itself,//' over that:
Yes, sure.

 And besides, it's not that we want Iceweasel, it's that we DO NOT WANT
 Firefox since it does not follow Fedora policies.

As it's obvious from the discussion: There are other we in Fedora that
think having Firefox is wise.

Please note that I actually don't feel myself as being a part of either
we here. Both sides afaics have good points. The main reason why I
raised my voice: I don't see a real reason why Fedora has to pick a
position for the repository (see next para)

 Having both would not actually solve any problem.

I tend to disagree, as including both Iceweasel and Icedove in addition
to Firefox and Thunderbird gives users, admins and especially those that
maintain a remix the option to easily chose the solution that suites
their needs best.

Cu
knurd



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: xulrunner 2.0 in rawhide (F15) bundles several system libs

[Thorsten Leemhuis]

Kevin Kofler wrote on 02.10.2010 00:56:
 Sven Lankes wrote:
 https://bugzilla.mozilla.org/show_bug.cgi?id=577653
 Looking at how rigorous new packages with bundled libs are fought we
 should really stop shipping firefox and start shipping Iceweasel.
 +1
 
 I really don't see why the Firefox stack keeps getting a free ride around 
 our packaging guidelines. Firefox is a package like any others, it MUST 
 respect our packaging guidelines, and that means NO bundled libraries, 
 PERIOD. If that's not possible while still calling it Firefox, it MUST be 
 renamed.

Maybe I'm missed something, but there is a (relative) simple question
that always pops up in my head when I read things like this. I never
bothered to ask it in public, but I'll do now:

 * Why haven't those that want iceweasel and icedove in Fedora not
simply invested some time and got them integrated into the repository?(¹)

It wouldn't be the first (albeit it likely would be the biggest) fork
where we also still ship the original (dd{,_}rescue comes to my mind),
hence I'd assume the packaging guidelines do not forbid something like
that. Or do they?

CU
knurd

P.S.: No, I'm not trying to shoot down the discussion, as it looks like
it's in its last stages already anyway

(¹) or was I simply to blind to find the review requests in bugzilla
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Broadcom wifi drivers in F-14?

[Thorsten Leemhuis]

Hans de Goede wrote on 15.09.2010 08:31:
 On 09/14/2010 01:31 PM, David Woodhouse wrote:
 On Tue, 2010-09-14 at 00:40 -0700, Jesse Keating wrote:
 IIRC they require a firmware blob that has a license that we cannot 
 distribute
 unlike say the Intel firmwares. I could be wrong though.
 That's still true of the b43 firmware for older (pre-802.11n) devices,
 but the firmware to go with their new driver is now in
 linux-firmware.git.
 
 Hmm, now that they are trying to be opensource friendly, can't we get them
 to license the old firmware under the same license as the new one? It would
 be great to be able to ship the old firmware and haver older broadcom cards
 work out of the box.
 
 David do you have a contact inside Broadcom to talk to about this, and could
 you ask?

Just FYI, a question like that was already raised in public a few days
ago, but remains unanswered as of now afaics:

http://thread.gmane.org/gmane.linux.drivers.driver-project.devel/8460/focus=55447

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)

[Thorsten Leemhuis]

Toshio Kuratomi wrote on 15.09.2010 04:54:
 On Tue, Sep 14, 2010 at 07:02:33PM -0600, Kevin Fenzi wrote:
 On Tue, 14 Sep 2010 20:48:13 -0400
 Máirín Duffy du...@fedoraproject.org wrote:
  Only 5 of the 9 FESCo members voted on this issue. If all 9 had voted,
  even with the current 3 for / 2 against vote, systemd could easily
  have enough votes for inclusion in F14. I have a couple of questions
  for you, FESCo, since I honestly don't know and maybe would feel more
  comfortable knowing:
 ok. 
 
  - Has there been any consideration for formalizing the acceptable of
  absentee votes?
 no, but perhaps there should be?

Just a side note: That has problems of its own, as those votes might
happen before new aspects come up in the IRC discussion that normally
precedes the votes in IRC meetings...

  - How many members must be present at a meeting for a voting decision
  to be considered valid?
 My understanding: A quorum (ie, 5 of 9). 
 Note, in the distant past, FESCo's rule was majority of the folks present
 with an attempt made at unanimity by the present members by resolving (as
 much as possible) their differences in opinion.  This was actually stated in
 meetings but I don't think that it made it to the wiki -- thl might know as
 that was during his tenure as chair.

 However, I don't believe this rule has been followed in a *long* time so
 it might just be a historical footnote to this conversation.

Yes, back then we afaics tried a whole lot harder to make everyone
happy. That included even non-FESCo members that tried to raise options
on a particular topic on the list or in IRC meeting; we even let those
non-FESCo-members share a (mostly unofficial) vote on IRC, as those
votes often influenced how FESCo member voted (which IMHO was a good thing).

Some of that obviously would be much harder to do these days, as FESCo
has lot more to deal with and Fedora has way more contributors. But that
doesn't mean part of it could be tried again.

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: web-m and Fedora 14

[Thorsten Leemhuis]

On 20.05.2010 18:42, Jesse Keating wrote:
 On Thu, 2010-05-20 at 14:25 +0100, Bastien Nocera wrote:
 I'd expect most of the support to end up in F13 updates, so I'm not
 sure a feature page really makes sense. 
 This happens with a lot of our features anyway, [...]

And that imho is quite bad for everyone involved, as it kind of makes
everyone unhappy afaics.

To explain: Journalists (even those that are familiar with Fedora) can't
know each and every details of Fedora and thus rely on those feature
pages quite a lot. So after reading
http://fedoraproject.org/wiki/Features/KDE44 (¹) they might write (for
example) something like One of the new interesting things in Fedora 13
is KDE 4.4 .

But most people that already use KDE and Fedora 12 will know: that's
nothing new, I already got that version via updates weeks ago. So they
will think the journalists is not well informed, I don't need to read
this article any further. Some might ever write to the journalist you
wrote crap, this is nothing new. So he might be angry with the Fedora
project, as the information it provided misguided him. That might
influence his writing for later releases, which is not what we want.

CU
knurd

(¹) Yes, that page contains Currently KDE 4.4.2 is packaged in the
devel and Fedora 13 branches and also shipped in updates to Fedora 11
and 12.. But journalists are busy people and might not have time to
read each and every feature page completely (and might miss is easily
if they do).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Features in new releases / updates

[Thorsten Leemhuis]

On 22.05.2010 11:59, Matt McCutchen wrote:
 On Sat, 2010-05-22 at 10:14 +0200, Thorsten Leemhuis wrote:
 On 20.05.2010 18:42, Jesse Keating wrote:
 On Thu, 2010-05-20 at 14:25 +0100, Bastien Nocera wrote:
 I'd expect most of the support to end up in F13 updates, so I'm not
 sure a feature page really makes sense. 
 This happens with a lot of our features anyway, [...]
 And that imho is quite bad for everyone involved, as it kind of makes
 everyone unhappy afaics.
 To explain: [...]
 [...]
 Without addressing other reasons, I think keeping the situation simple
 for journalists is a pretty weak reason not to add a feature to an
 existing release via updates.

I didn't meant to imply this anywhere (in fact I think updates like that
are a really good thing and one things that makes Fedora better than
other distributions for me). I just wanted to express that it has
downsides to have a feature page for something that is not new at all.

CU
knurd

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Conflicts in latest update

[Thorsten Leemhuis]

Jon Masters wrote on 16.03.2010 13:04:
 On Tue, 2010-03-16 at 11:16 +0100, Matěj Cepl wrote:
 Dne 16.3.2010 09:50, Ankur Sinha napsal(a):
  I did notice that. I wasn't sure why a package from rpmfusion would
  conflict with one from fedora repos. (It's in rpmfusion for a reason)
  Is it being obsoleted by a fedora package (license been cleared or
  something)?
 
 There are constantly modules moving between -good, -bad, -ugly packages 
 of gstreamer, and sometimes rpmfusion packages are not in sync with 
 Fedora ones. Give rpmfusion packagers some time to fix it (or join them 
 and help to fix it on your own).
 
 I'd just add those gstreamer packages to my exclude config in yum for
 the moment, if you don't want to deal with the breakage each time. Then
 you can remove those excludes when the repos catch up with each other.
 
 /etc/yum.conf:
 
 exclude=gstreamer-plugins-bad-free gstreamer-plugins-good

There are so many developers around on this list that know: reporting
bugs is the right way to get problems fixed and fixing things is way
better than posting workarounds to public places for various reasons --
nevertheless nobody filed a bug yet afaics  :-/

CU
thl

P.S.: A updated gst-plugins-bad package that afaik solves the problem in
question was pushed to the proper RPM Fusion repos one or two hours ago,
so there is no need to report a bug anymore afaics -- but people will
continue to see the problem for the next ~24 hours or so due to
mirror-lag and caching issues
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Conflicts in latest update

[Thorsten Leemhuis]

Ankur Sinha wrote on 16.03.2010 14:33:
 On Tue, 2010-03-16 at 13:45 +0100, Thorsten Leemhuis wrote:
 Jon Masters wrote on 16.03.2010 13:04:
  On Tue, 2010-03-16 at 11:16 +0100, Matěj Cepl wrote:
  Dne 16.3.2010 09:50, Ankur Sinha napsal(a):
   I did notice that. I wasn't sure why a package from rpmfusion would
   conflict with one from fedora repos. (It's in rpmfusion for a reason)
   Is it being obsoleted by a fedora package (license been cleared or
   something)?
  There are constantly modules moving between -good, -bad, -ugly packages 
  of gstreamer, and sometimes rpmfusion packages are not in sync with 
  Fedora ones. Give rpmfusion packagers some time to fix it (or join them 
  and help to fix it on your own).
  I'd just add those gstreamer packages to my exclude config in yum for
  the moment, if you don't want to deal with the breakage each time. Then
  you can remove those excludes when the repos catch up with each other.
  /etc/yum.conf:
  exclude=gstreamer-plugins-bad-free gstreamer-plugins-good
 There are so many developers around on this list that know: reporting
 bugs is the right way to get problems fixed and fixing things is way
 better than posting workarounds to public places for various reasons --
 nevertheless nobody filed a bug yet afaics  :-/
 [...]
 I'm really grateful for the info.

np

 I didn't have enough knowledge on the transitions going on wrt gst packages

In case you got it wrong: my There are so many developers around on
this list that know... rant was not sent in your direction ;-)

 which is why I hadn't reported a bug yet. The intention of the thread
 here was to get more info on what was going on.

That's fine, but OTOH: A lot of people seem to think like that and that
afaics often leads to a situation where nobody reports the bug :-/ Note
that this is not specific to RPM Fusion, it's a general problem that
just worse when it comes to RPM Fusion, as it only has a quite small
number of contributors...

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Conflicts in latest update

[Thorsten Leemhuis]

On 16.03.2010 17:42, Till Maas wrote:
 On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote:
 There are so many developers around on this list that know: reporting
 bugs is the right way to get problems fixed and fixing things is way
 better than posting workarounds to public places for various reasons --
 nevertheless nobody filed a bug yet afaics  :-/
 Imho it was not that obvious that there is a bug present, because these
 kind of delays are usual with RPMFusion, because the repos are not
 directly synced.

That IMHO something that needs fixing on the Fedora side (e.g. in yum)
http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
But I lost energy driving a solution forward.

 E.g. I just expected it to work within some days and if
 it did not, then I would have thought there might be something wrong.

Well, there were a few cases in the past where problems like this one
persisted for a few days because everybody thought like you outline :-/
But I have no solution for that apart from if in a doubt file a bug :-(

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Conflicts in latest update

[Thorsten Leemhuis]

On 16.03.2010 20:46, James Antill wrote:
 On Tue, 2010-03-16 at 20:09 +0100, Thorsten Leemhuis wrote:
 On 16.03.2010 17:42, Till Maas wrote:
 On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote:
 There are so many developers around on this list that know: reporting
 bugs is the right way to get problems fixed and fixing things is way
 better than posting workarounds to public places for various reasons --
 nevertheless nobody filed a bug yet afaics  :-/
 Imho it was not that obvious that there is a bug present, because these
 kind of delays are usual with RPMFusion, because the repos are not
 directly synced.
 That IMHO something that needs fixing on the Fedora side (e.g. in yum)
 http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
 But I lost energy driving a solution forward.
  I'm not sure what you want us to do,

Actually I'm not sure myself what to do and haven't put much thought
into it lately...

 the main problem is that splitting
 a DB of packages and then stitching it back together doesn't work 100%
 of the time ... this isn't us being stupid:
 http://en.wikipedia.org/wiki/CAP_Theorem
 ...yum repo DBs are AP and not C.

Well, the big hammer solution to make it work 100% of the time then
would be: RPM Fusion should disable the Fedora repos and provide the
matching repodata for Fedora itself.

But that solution would be over designed, complicated and inflexible, so
don't take that suggestion seriously ;-)

But I don't think 100% of the time is needed, but maybe it could be made
a lot whole lot better with some fine tuning. The simple solution that
would fix most of the problems afaics: an additional config value flag
in (say) rpmfusion-free-updates.repo that expresses if repo
fedora-updates gets updated repodata then check for updated
rpmfusion-free-repodata not only on the mirrors of this configured repo,
but also on server download1.rpmfusion.org (master repo for RPM
Fusion). Then everything should just work for people as long as RPM
Fusion pushed matching updates in parallel. Note that the stuff needs to
work vice versa as -- e.g. if yum sees updated repo data for RPM Fusion
then check for new fedora-updates repodata as well.

  Skip-broken helps in all cases apart from file conflicts, which is a
 packaging bug. 

Or a mirror lag and cache problems, like it would have happened with
gst-plugins-bad if we had pushed it at the right time, as in some cases
a freshly updated fedora-updates repo will get combined with a outdated
rpmfusion updates repo from a not-yet-updated mirror (or vice versa).

 Your idea of timed skip-broken by default doesn't work

That was just me thinking out loud ;-) and it's not my preferred
solution for the problem at hand these days...

 because we don't have a date package was released ...

And would that be needed at all? The timer could simply start locally
then yum sees the problem seen for the first time.

But as I said: Not sure if that worth investigating, but it might, as
yum bailing out when a problem happens seems to confuse quite a lot of
people (a colleague of mine for example always gets annoyed by that and
asks for help). Sure, those that don't know how to deal with it might
better be using PK, but we can't force them to do that and those
problems make us look bad :-/


Anyway: the timed skip-broken by default has a big downside in any
case: you might lose features temporary. Let's assume new gstreamer
packages where a plugin was moved from -bad to -good. Let's further
assume Fedora and RPM Fusion would have shipped the new matching and
updated packages in parallel. Then yum on some systems will install the
new -bad package from rpmfusion (which lacks the plugin now) but not the
new -good package from Fedora, if the mirror yum chose was not updated
yet (or updated a few hours earlied and was not checked for updated
repodata due to caching). Than the user temporary looses a feature --
bad :-/

 E.g. I just expected it to work within some days and if
 it did not, then I would have thought there might be something wrong.
 Well, there were a few cases in the past where problems like this one
 persisted for a few days because everybody thought like you outline :-/
 But I have no solution for that apart from if in a doubt file a bug :-(
  Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't
 think we can legally do the same ... but I'm not sure). Finding the file
 conflicts automatically is harder (you need to download all the rpms),
 and it's not fast, but it's possible (Seth has a script, IIRC).

Yeah, sure, that's right, but there were other information that made be
write the above:

RPM Fusion has just a few contributors and so little man-power, it
didn't even manage to get the repo closure scripts running on their own
hosts regularly -- there were some attempts over the years, but nothing
came out of it :-/

I fear that the lack of man power and contributors will result in RPM
Fusion falling apart sooner

Re: hdparm -B for netbooks

[Thorsten Leemhuis]

Matthew Garrett wrote on 23.02.2010 23:09:
 On Tue, Feb 23, 2010 at 09:34:54PM +0100, Richard Zidlicky wrote:
 
 it was my understanding that hdparm -B has nothing to do with the BIOS but 
 changes 
 the power management feature specific to the drive?
 Either the drive set the initial value, or the BIOS did. We tend to 
 assume that there was some reason for that...

And what does Windows do? I have the strange feeling it doesn't assume
the same and instead simply sets something it thinks is sensible, which
afaics results in Hardware manufactures not to care much what the
initial value for the drive is or what the BIOS sets. If that's the case
(I never checked and am not familiar with Windows enough to know) then
wouldn't it be the most sensible thing to do something similar?

CU
knurd

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Board efforts: scope, concept, and permission?

[Thorsten Leemhuis]

Kevin Kofler wrote on 03.02.2010 19:08:
 Josh Boyer wrote:
 It is.  It's one step removed.  There were people actively wanting to make
 Zope/Plone work via a compat-python stack.  It went all the way to FESCo
 and got voted down.  The zope/plone users were the target audience there.
 There were people willing to do the work, all they needed was a yes from
 FESCo.  We told them no.  As Jesse has mentioned, 'status quo' won out.
 I think this was just a bad decision. I complained back then and I still 
 think we did the wrong thing.

Strong +1 to this

 We should be as encompassing as legally 
 possible within our Free Software ideals. Those packages eventually ended up 
 in RPM Fusion anyway, like most of the stuff we refuse, so what was the 
 point of preventing them from going into Fedora? Supportability concerns 
 aren't going to vanish just because the package ends up in a third-party 
 repository, and we have no way to prevent that.
 
 I also think for the same reasons that we should allow acceptably-licensed 
 (GPLv2 or compatible) kernel modules as external packages in Fedora, banning 
 them gains us nothing and loses us hardware support we could gain without 
 any moral (software freedom) compromises or legal risks.

As one of those behind the kmod stuff and someone interested in the
topic for years: I think having the kernel modules outside of Fedora is
very good thing, as that makes it quite clear to everyone: This is
unsupported by Fedora and its upstream source and hence might be crap
and vanish at any time; don't rely on it and don't buy (or suggest
others buying) hardware that is supported by this crap like this.

Further: In the end it afaics all boils does to the if it's not good
for the official kernel, why should it be good enough for Fedora.

By shipping that stuff we also might cannibalize upstream, which is not
good for everyone in the long term most of the time and afaics. Or, IOW:
The more changes and out-of-tree stuff Fedora integrates into its kernel
the closer we get to a mess like the one with Android that is currently
discussed quite a lot on the net ( http://lwn.net/Articles/372419/ and
the comments there ). Sure, it is unlikely that it becomes that bad for
us, but I for one would prefer if Fedora would not even go down that
route at all and works so close with upstream that we ideally can ship
vanilla kernels.

Cu
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel