Re: What is Fedora?

[Gerald Henriksen]

On Wed, 21 Jun 2023 21:06:40 +0100, you wrote:

>Hi all,
>
>Obviously many will have seen:
>
>https://www.redhat.com/en/blog/furthering-evolution-centos-stream
>
>and see, where EL (contributors like you of fedora/EPEL) have been knocked 
>down:
>
>https://bugzilla.redhat.com/show_bug.cgi?id=2215299
>
>Let us face it our efforts with the Fedora project are not valued and it is a 
>means nothing to the
>new corporate IBM/Red Hat enterprise systems that we have to struggle to get 
>access to srpms, to
>make a community. What is community now to Red Hat?

My interpretation of the blog post, combined with recent actions
towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as
the new "Fedora" for basing future versions of RHEL.

___
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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Gerald Henriksen]

On Sat, 28 May 2022 20:52:51 +0200, you wrote:

>On 28/05/2022 19:31, drago01 wrote:
>> That's incorrect. They can be outdated, but there is no inherit reason 
>> why they have to be.
>
>Most upstreams don't care about bundled libraries. They bundle them once 
>and then forget.

But most != all as you claimed.

There is no indication that the JDK is such a thing - in fact given
the packagers are struggling that is a good indication that the JDK is
being regularly updated.
___
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: F35 Change: "Fedora Linux" in /etc/os-release

[Gerald Henriksen]

On Sat, 13 Mar 2021 11:00:12 -0500, you wrote:

>On Fri, Mar 12, 2021 at 08:13:07PM -0500, Gerald Henriksen wrote:
>> You aren't going to change not just the 15+ year habits of how people
>> refer to Fedora, but the even longer habits of how people call Linux
>> distributions.
>
>Again, I'm not out to immediately change colloquial usage. Although I *do*
>think that would be a positive, that's not in scope here. It's about how we
>formally talk about things ourselves, and this change is just about one very
>specific small way in which we do that.

So, a community that historically hates typing extra stuff and thus
likes to remove vowels and occasionally other letters from commands,
who primarily "talks" via text communication, is suddenly going to add
the extra word Linux in their communications?

Yes, you will be able to force the web team to add the word Linux to
every mention of Fedora - but no one else is going to.

Which again brings us to what is the point then?

If you want to differentiate the OS from the project and other stuff,
then you are going to be better off renaming the other stuff than
attempting to force through a change to a name that the community and
outside world aren't going to follow.
___
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: F35 Change: "Fedora Linux" in /etc/os-release

[Gerald Henriksen]

On Thu, 11 Mar 2021 11:21:18 -0500, you wrote:

>I would put it this way: this change _helps recognize_ that Fedora is more
>than its main product. This isn't new; EPEL has been part of Fedora since
>the beginning, and CoreOS has been since it replaced Project Atomic.

You want this change to do that, it will fail to do that.

You aren't going to change not just the 15+ year habits of how people
refer to Fedora, but the even longer habits of how people call Linux
distributions.

Regardless of what their official titles are the public all refer to
them by their simple names - Fedora, Debian, Ubuntu, Suse, Red Hat,
Centos, etc.

You can change the website, but you won't change how the public names
Fedora.

Which means it won't achieve your stated goal.
___
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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Gerald Henriksen]

On Wed, 1 Jul 2020 14:24:37 -0400, you wrote:

>On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek wrote:
>> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
>> could be good option. I know technically it is already opt-in, but it's not
>> very visible or popular. We could make the btrfs option more prominent and
>> ask people to pick it if they are ready to handle potential fallout.
>
>I'm leaning towards recommending this as well. I feel like we don't have
>good data to make a decision on -- the work that Red Hat did previously when
>making a decision was 1) years ago and 2) server-focused, and the Facebook
>production usage is encouraging but also not the same use case. I'm
>particularly concerned about metadata corruption fragility as noted in the
>Usenix paper. (It'd be nice if we could do something about that!)

So if one has a spare partition to play with btrfs, is there an easy
way to install a second copy of Fedora without having the /boot/efi/
entries overwrite the existing Fedora installation?  Or fix it to have
2 separate entries after the fact?
___
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Gerald Henriksen]

On Mon, 29 Jun 2020 10:47:58 +0200, you wrote:

>since vim addresses this when opened without a file and it is open
>source, it seems to me to be a good idea to propose to adjust vim
>behaviour to show the help overview when opening a file as well. For
>example if there is no ~/.vimrc or some other indicator that shows the
>user does not know vim, yet.

While it may be worth vim making themselves better, it really doesn't
change the argument.

Even a friendlier vim is still going to be far to strange and
confusing to somebody just looking to quickly change a setting and get
on with Fedora.
___
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

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Gerald Henriksen]

On Sun, 28 Jun 2020 09:59:52 -0700, you wrote:

>Has that actually been explored? How does Canonical get around the legal 
>issues with OpenZFS' licensing?

For a start they aren't a US company, and unlike Red Hat they aren't
the same tempting target for a lawsuit.
___
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Gerald Henriksen]

On Fri, 26 Jun 2020 13:23:17 -0400, you wrote:

>Heres a thought that I hadn't considered before though, and it might be useful.
>Apple at one point (and still may), shiped iphones without the itunes (or some
>common) app on it,
>and they did so intentionally, because they knew it was an app that people
>wanted, and it forced them into a sort of 'training mission' in which they had
>to use the app store on their phone to find and install the itunes app.  It 
>gave
>end users, after their initial disgruntledness, the skills to install new apps
>on their phone, and explore how some of the system worked.

I can't comment if that was ever true, but it certainly hasn't been
the case for a very long time - it wasn't an issue on the first iPad.

>Would that be a possibility here?  I've upgraded my fedora workstation so many
>times, I'm not sure what our firstboot screens look like anymore, but would it
>be worthwhile to present users with some text, or a guide wizard, to point out
>files like their ~/.bashrc file with some commented text that shows clearly 
>what
>some useful environment variables are, and how they might set them to customize
>their experience?  Its not very 'just press the button to do something you may
>or may not understand', but it targets new users as part of firstboot, and
>introduces them in a somewhat friendly way to how things look under the covers,
>so they can make adjustments as their needs dictate.

At which point they realize choosing Fedora was a mistake, and they go
to Ubuntu like all their friends suggested in the first place.
___
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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Gerald Henriksen]

On Tue, 16 Jun 2020 15:05:41 -0400, you wrote:

>User/Admin customizations are expected to be retained post-upgrade, and 
>software installed after the fact absolutely counts as a customization, 
>no matter where that software came from.

But any software installed by the user that comes from an official
Fedora repo is installed on the assumption that it is being maintained
by Fedora - that is why it is in the Fedora repo.

If the software is no longer being maintained (either due to a lack of
a packager, or because upstream has disappeared) that implied contract
is no longer true.

>And what about non-Fedora software?  That can break an upgrade too, are 
>we going to automagically remove that stuff too?  If not, Fedora will 
>still going to have to handle those upgrade failures gracefully.

Any software installed from non-Fedora sources will involve a decision
by the user to accept that it is not being supported by Fedora.

This should (although sadly likely doesn't) mean that the user pays
attention as to whether the software is being updated and supported or
not.

>But.  I cannot strongly object enough to automatically uninstalling a 
>package solely because it was retired, because "retired" does not mean 
>"broken".

Given the number of cases of evil people getting access to computer
systems, and the fallout of said attacks, any package left on a system
after it no longer is being maintained is not only broken but a
security risk.

You as a user may wish to explicitly make the decision to ignore that
risk and keep or re-install that software, and that is your choice.
But it should not be the default behaviour of the distribution.
___
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

Re: unretiring llvm7.0

[Gerald Henriksen]

On Sat, 30 May 2020 18:43:03 +0200, you wrote:

>If I understand correctly, the sudden disappearance of llvm7.0 means that
>now ghc is in danger as a package, because it's missing the toolchain
>needed to build & package it?

Don't know anything about ghc to comment on the difficulties, but ghc
8.10.1 was released 2 months ago and uses llvm 9

>However, https://apps.fedoraproject.org/packages lists only llvm9.0 and
>llvm10.0 builds.
>
>I think it's an interesting problem in general. Perhaps it would be good to
>have at least 1 extra version of GCC and LLVM other than the current
>mainline?

Isn't that already happening though with both llvm (10) and llvm9.0
being available in Fedora 32?
___
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

Re: Re-Launching the Java SIG

[Gerald Henriksen]

On Mon, 18 May 2020 18:03:16 -0500, you wrote:

>X. Org as root is **STILL** the standard and Fedora broke it. This is 
>why no one wants to support Linux: you constantly break your own 
>platform and then cry wolf when people who don't care about your 
>ideological nonsense refuse to fix their software that was working 
>perfectly fine before.

X.org running as root likely is a security risk, and as such it is
long past the point where somebody should have fixed it.

And with time the other distros will probably also change X.org to run
as a user instead of root (ie. once all the bugs are worked out).

So not a very good arguement.
___
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

Re: Re-Launching the Java SIG

[Gerald Henriksen]

On Thu, 14 May 2020 06:33:47 -0500, you wrote:

>* Game developers largely refuse to support Linux, and the some of the 
>few that have have or are currently pulling support citing 
>fragmentation(support) issues.

Game developers refuse to support Linux because there is no userbase -
even Steam, who moved to Linux for strategic rather than financial
reasons, consistently reports a neglible installed base of Linux
gamers.

The fragmentation may not help, but it isn't the driving force (if
Linux gaming was a $10billion a year business they would find a way to
deal with the issues).

>* Hardware support for AMD GPUs is all over the place and even if 
>technically supported, can be too buggy to use. This is largely because 
>kernel/mesa versions are all over the place.

Surprise, writing drivers and the associated code for modern GPU's is
hard - even for the in house development teams providing binary only
drivers, as anyone who follows GPU issues on Windows is aware.

>* You often need to install third-party repos to get up-to-date software 
>since packages are way too slow, or the distros just choose to use very 
>old software(Debian).

Part of choosing a distro is choosing new vs well tested.

Anyone choosing the released versions of Debian is doing so on the
basis they want well tested releases and new versions aren't a
priority.

If you want new version, you choose a different distro.

>* Bugs fixed in newer versions of Gnome shell aren't backported to older 
>versions. It looks like they have extended support, but I doubt it's for 
>the same amount of time Ubuntu supports an LTS. Even if it did, only 
>newer Gnome shell versions are supported for that long. 18.04 probably 
>has shell bugs right now that are fixed in newer Gnome versions.

Not a Gnome problem (says a person who doesn't even like Gnome
anymore).

When Ubuntu/Red Hat/CentOS/etc release whatever their variation of a
distro with a long support lifetime is they take on the burden of
supporting the software for the duration of that release, not the
upstream.

So in your complaint, it is not up to Gnome to continue supporting
that version of Gnome, it is up to Ubuntu to backport/create fixes as
necessary - that is after all the whole point of offering a LTS
release that people pay Ubuntu to provide support on.
___
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

Re: Re-Launching the Java SIG

[Gerald Henriksen]

On Thu, 14 May 2020 06:59:47 -0500, you wrote:

>What i'm saying is: Distros like Fedora actively hurt the very people 
>who are directly or indirectly helping them. There are single-person run 
>projects, like mine, out there that can't possibly do all the work 
>needed to have a dozen packages for each distro. It's just not possible 
>or, in the case of Java based projects, not even needed to begin with.

1) nobody is forcing upstream developers to package their projects -
that's what the packagers in the various distrobutions do.

2) the fact that people want to package the Java packages, and that
other people want to install those packages, indicates that there is a
need.

>That is to say nothing of those distros doing things like Fedora now 
>does like running X as user which break otherwise perfectly running 
>applications. 

Running X as a user would be a change done to decrease the security
risk of running applications using X, or X itself.

It is the type of change that anyone should expect a distribution to
make, and the type of change even Apple and Microsoft make (anyone who
used Windows in the past will recall the applications that insisted on
being run as an Administrator for no valid reason, and eventually
Microsoft learned the hard way and cracked down - I am sure just like
you seem to be a lot of Windows developers made the same false claim
that MS was breaking otherwise perfectly running applications.

>I can't check in every 6 months to make sure y'all didn't 
>break something.

Then perhaps you need to look for a different hobby/career?

The software development field is full of constant change that
developers need to be aware of regardless of OS or environment.
___
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

Re: Re-Launching the Java SIG

[Gerald Henriksen]

On Tue, 12 May 2020 15:58:39 -0500, you wrote:

>As someone who has been burned due to Fedora's goody little two shoes 
>policies, I'd kindly ask that Fedora take a hike and not package the 
>software at all.

The only way to make sure that the stuff included with Fedora is open
source is to build it from source - simply grabbing a binary provided
by an upstream means upstream could slip in some closed source
portions or have such a complex and undocumented build system that the
project may as well be closed source because no one else can build it.
___
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

Re: Getting security updates out to users sooner

[Gerald Henriksen]

On Thu, 16 Apr 2020 18:14:29 -0700, you wrote:

>On Fri, 2020-04-17 at 01:01 +, Demi M. Obenour wrote:
>> Currently, security updates can take days to get to users.  In
>> particular, Firefox and Thunderbird often take a day or more, even
>> though virtually every single update contains security fixes.
>> 
>> We need to ensure that security updates reach stable within hours of
>> an upstream advisory.
>
>Why?

At least a recent Firefox update was to fix 2 issues that were
reported as being already exploited in the real world.

https://www.zdnet.com/article/firefox-gets-fixes-for-two-zero-days-exploited-in-the-wild/

Whether a security risk on Linux isn't indicated, but users shouldn't
have to wonder why the media is telling them Firefox needs an
immediate update and it isn't being provided by their distribution.
___
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

Re: Nvidia binary drivers fail to install on Fedora 32

[Gerald Henriksen]

On Sun, 29 Mar 2020 06:46:17 -, you wrote:

>> Wait, nevermind. It’s kmod, got them confused:
>> 
>> 
>> rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
>
>You need to use the nodebug kernel
>
>https://fedoraproject.org/wiki/RawhideKernelNodebug
>

And just how wise is it putting Rawhide kernels into a Fedora 32
system?
___
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

Re: Package uses Gradle (retired) to build: what to do?

[Gerald Henriksen]

On Sat, 8 Feb 2020 19:16:45 -0500, you wrote:

>What does it tell? To me, it says that FOSS platforms don't care about
>Java as much as they used to. We're clearly able to do stuff with Go
>and Rust, which are just as "anti-distribution" as Java is (based on
>what other people say).

Go and Rust have the advantage that the build system is included in
the language, so packagers don't have to attempt to package x
different build systems (and because they are included, they also
don't tend to have an expanding with time dependency list).
___
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

Re: Package uses Gradle (retired) to build: what to do?

[Gerald Henriksen]

On Sat, 8 Feb 2020 18:50:25 +0100, you wrote:

>> and why gradle was retired ? is easy unretire it ?
>
>I am running gradle command right now as a coincidence .
>
>The upstream project is active.
>https://github.com/gradle/gradle
>
>We also might refer other distribution's spec files if we unretire.
>https://software.opensuse.org/package/gradle
>https://tracker.debian.org/pkg/gradle

They are unlikely to be of much help given how out of date they are.
Gradle is currently at 6.1.1 and Debian seems to be packaging 4.4.1
and OpenSuse is at 3.2.1.  Ubuntu seems to be 4.7

The other message that posted the link to the email regarding the
removeal of Gradle indicated a lot more dependencies were added since
those versions were packaged.

It is telling when essentially none of the open source operating
systems have a current gradle version (FreeBSD does, but they just
grab and wrap the binary from the Gradle website) that gets built from
source.
___
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

Re: Java Dev Group and Fedora Quality

[Gerald Henriksen]

On Sun, 26 Jan 2020 22:33:55 -, you wrote:

>> That's not really fair. DNF is pretty much only the user interface,
>> and everything it's built on top of (hawkey, librepo, libsolv) is
>> implemented in C / C++. And when I think back to using yum, dnf is
>> really fast :)

>> I don't know which performance problems you have with python - which
>> components (written in python) do you think cause bottlenecks here?
>
>dnf

Except as per above, the peformance parts of dnf aren't written in
Python anyway.

>firewalld is using 37MB right now on my desktop. If it was written in Java it 
>would be using more. But if it was written in C/C++ it would be less than half 
>that size. It's not terrible I guess, compared to other things. I just really 
>prefer more efficiency at this level because when you start allowing this for 
>more and more programs that extra memory usage adds up.

I believe you said your machine had 8GB, so that means firewalld is
using an extravagant 0.4% of your memory.

Now yes, in theory (I say theory because you need to find a volunteer
to do it) someone could rewrite in a different language and save you
0.2% of your memory.

But is that really a good use of scarce resources?

>I respect your opinion here. But, I feel that as the hardware guys provide 
>more RAM, we shouldn't be wasting it. Because we waste a little RAM here and 
>then there and eventually every program is wasteful and all that waste adds 
>up. You end up with a poorly performing system even though it has plenty of 
>RAM. We need to bring back a culture of efficiency rather than wastefulness. 

It's a trade off - one of the reasons presumably you are programming
in Java is because it makes you more productive than writing in C.

We exchange hardware use for productivity because developer time is
far more expensive and scarce a resource than hardware is.

>OK, I don't know about this but I believe you. I'm just looking at it from a 
>user's perspective that there are a lot of problems and makes me thing that 
>not enough testing is being done.

Have you looked at the complaints that the users of Windows and Apple
products have these days?  It makes Fedora look really, really good. I
mean, Microsoft's answer to their quality control problems on Windows
appears to be shipping updates that don't do anything new...
___
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

Re: Announcing fmt library soversion bump

[Gerald Henriksen]

On Wed, 18 Dec 2019 15:30:57 +0100, you wrote:

>On Wed, Dec 18, 2019, 14:44 Vitaly Zaitsev via devel <
>devel@lists.fedoraproject.org> wrote:

>> Fmt 6.1.2 build completed for Rawhide. It include SOVERSION bump. All
>> dependent packages need to be rebuilded.
>
>
>It would be great to announce this stuff a week in advance, so maintainers
>of dependent packages can coordinate the necessary rebuilds ... announcing
>it like "this happened, now deal with it" (without even including a list of
>packages that needs to be rebuilt) isn't really helpful.

It would also likely be considerate not to do this just prior to a
major holiday, when a lot of people are attempting to get stuff done
prior to being gone for 1 or 2 weeks and so have a heavier workload.
___
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

Re: [fedora-java] What's the State of the Java SIG?

[Gerald Henriksen]

On Mon, 18 Nov 2019 21:08:02 -0800, you wrote:

>On 11/18/19 7:29 PM, Neal Gompa wrote:
>> I can't speak for everyone, but at least my experience was that it was
>> functionally impossible to discover how to package Java stuff. In a
>> lifetime (and a job) ago, I was much more engaged in the Java
>> ecosystem. Back then, I tried to learn how to package and ship Java
>> stuff in Fedora. But the documentation was (and still is) incredibly
>> poor. I only managed to package one library, and it was not easy for
>> me to figure out how to do it. The amount of effort I expended to do
>> it put me off to doing more in the Java ecosystem.
>
>Maybe I misunderstood the earlier comment.  I understand that Java can 
>be difficult to package, but I thought Gerald was saying that using 
>modules somehow made it easier.

I have no idea whether modules make it easier or not.

My point was that the Java SIG collapsed long before the modules
became an issue, so "rebooting" the Java SIG isn't going to change
anything unless those calling for the reboot come up with packagers
for the Java ecosystem.

And one of the reasons few want to package Java stuff is that because
for most of the Java stuff the users prefer to simply install the
provided jdk/jre and then download the jar files from upstream,
because by using official upstream provided jar files they can get
help from upstream with any problems.
___
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

Re: [fedora-java] What's the State of the Java SIG?

[Gerald Henriksen]

On Mon, 18 Nov 2019 13:37:39 +0100, you wrote:

>Fabio Valentini wrote:
>> Or is it time for a "tabula rasa" and restart the SIG?
>
>IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form the 
>current remains of the Java SIG and create a new Java SIG from scratch that 
>actually cares about packaging Java properly in and for (non-modular) 
>Fedora.

Great, you eliminate the remaining members of the Java SIG (those who
didn't go running away because forcing Java stuff into RPMs was too
painful).

Now where are you going to get new members to create this new Java
SIG?

I mean, the Java SIG isn't forcing Java packagers to use Modularity,
so that isn't why the Java SIG is dying.

The only reason modularity is an issue is because no one else wants to
maintain Java packages in the first place.
___
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

Re: Switching Maven and Ant to OpenJDK 11

[Gerald Henriksen]

On Sat, 26 Oct 2019 15:59:27 +0200, you wrote:

>On Sat, Oct 26, 2019 at 03:53:28PM +0200, Jiri Vanek wrote:
>> any package can switch to jdk11, but sysem jdk should be jdk8, at least for 
>> some more time...
>
>  Any reasons?  Defaulting to ancient software conflicts with our “First” 
> foundation.

Simple reason - while Oracle decided to move Java to a faster, time
based release cycle the Java community essentially shrugged the
proverbial shoulders and ignored Oracle.

Much of the Java ecosystem is still only supported on Java 8, and if
you go to adoptopenjdk.net the default choice remains Java 8.

Hadoop, Tomcat, etc. all still are only supported by their communities
on Java 8.

So while it might be noble for Fedora to try and force the issue, the
likely result is that users needing Java will simply use a different
distribution while Fedora will get a bad repuation in the Java
community.
___
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

Re: [fedora-java] Re: Switching Maven and Ant to OpenJDK 11

[Gerald Henriksen]

On Sat, 26 Oct 2019 10:33:59 -0400, you wrote:

>On Sat, Oct 26, 2019 at 9:53 AM Jiri Vanek  wrote:
>>
>> any package can switch to jdk11, but sysem jdk should be jdk8, at least for 
>> some more time...
>>
>
>If anything, we're late to the party of moving to JDK 11 by default.
>Java 8 has been EOL for a while now.

Given that Java 8 is the default in the new RHEL 8 I suspect it will
be getting support for quite a while yet.
___
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

Re: Let's revisit the FTBFS policy

[Gerald Henriksen]

On Wed, 14 Aug 2019 11:23:53 -0500, you wrote:

>So in summary, I guess I mostly support allowing packages which can't be
>rebuilt to stay in the distribution as long as they actually work and
>aren't causing maintenance burden elsewhere

On the other hand, unbuildable packages could be viewed as a security
risk.

If you can't just fix the security issue and rebuild, but instead have
to also fix the issue(s) that prevent the package from rebuilding this
could cause delays in getting a security update out.
___
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

Re: Fedora 31 Self-Contained Change proposal: AArch64 Xfce Desktop image

[Gerald Henriksen]

On Wed, 24 Jul 2019 09:28:12 +, you wrote:

>On Tue, Jul 23, 2019 at 03:12:29PM -0400, Ben Cotton wrote:
>> We currently offer Workstation, Minimal and Server images for use with
>> AArch64 Single Board Computer's (SBC's). We would like to add a
>> lighter weight desktop image for hardware that lacks the ability to
>> run accelerated desktops.
>
>Are people using gnome-shell on arm64 machines? Would it make sense to
>simply switch Workstation default to xfce on arm64?

There are finally better ARM boards coming out with more memory (the
new Pi 4 has a 4GB option) so going forward Gnome or KDE should become
more viable for at least some of these boards.

So an alternative to Workstation for the lower specification boards
would seem a better option in addition to the other mentioned issue of
what Workstation actually means in a Fedora context.
___
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

Re: Fedora Data Engineering SIG: interested in a Fedora SIG to work on this?

[Gerald Henriksen]

On Fri, 5 Jul 2019 11:23:06 +0800, you wrote:

>I think documentation alone is not enough to make things easy, as to make
>the software better integrate with Fedora would require some more
>additional work (eg: systemd integration, quick painless installation,
>prebuilt binaries) ..
>
>What about docker images, or vendor-rpm, or automated install scripts
>approach?. Would that work?.

Not if it goes against what the users expect, as it doesn't matter if
your solution is superior if it is too different than what the
community expects / is used to.

Speaking generalities.

My position has evolved, and I have now taken the position that if a
language (like Python) has a built in infrastructure for package
installation I no longer install any Fedora packages beyond the basics
(ie the compiler/interpreter).

Whether it is good or bad, it is no longer worth fighting those
communities and instead I follow their "best practices" and use their
package systems.

You obviously can decide otherwise.

But based on the above, my advice is to see how the communities
operate and find out how best to make Fedora work for those
communities.  

For example, anything that uses the JVM it is likely the only thing
that will install from Fedora is OpenJDK - the communities built
around Java will not use distribution packaged versions of the
software, preferring to install via direct downloads or Maven.

Similiarly with Python, every blog post, video, or book states to do
"pip install ..." and it doesn't matter if an RPM is better integrated
into Fedora as few will go against the community.

Obviously there are exceptions, like anything written in C where they
don't (yet) have their own packaging system and so that stuff likely
should be packaged.

Which comes back to my original post suggesting documentation, as it
isn't so much about making things easy as just making the vast
majority of potential users aware that there are other Linux
alternatives other than say Ubuntu, which seems to dominate that
existing mindset of blog posts and other documentation.
___
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

Re: Fedora Data Engineering SIG: interested in a Fedora SIG to work on this?

[Gerald Henriksen]

On Thu, 4 Jul 2019 21:47:44 +0800, you wrote:

>yeah i agree .. my exp dealing with the tools highlights one tricky problem
>we might face -> avoiding statically / bundled dependencies , while on the
>same time getting all the tools to work .. most of them locks to specific
>dependency version, and wont work on other.. and at the moment i'm not sure
>whats the right approach to this, so really need input from others. My
>current workflow is to install each tool and all their dependencies in
>their own virtualenvs or vendor directory.

Perhaps then the best solution is to document it, and then the SIG if
created can do blog posts, videos, etc. to promote using Fedora using
a documented procedure that works?
___
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

Re: Fedora Data Engineering SIG: interested in a Fedora SIG to work on this?

[Gerald Henriksen]

On Thu, 4 Jul 2019 12:41:26 +0800, you wrote:

>Currently my idea on this SIG would be:
>1 - packaging data engineering related softwares into Fedora, and make them
>easy to install, covering from workflow tools (eg: airflow, luigi), data
>processing engines (eg: apache spark, flink), visualization tools
>(superset, redash) and make life easier for that. I'm not sure how much
>these tools can fit into fedora packaging guidelines (lots of bundled jars,
>and users expects upstream binaries, esp on engines such as spark/flink),
>which is something to brainstorm on.

I think this is likely a great idea, though I would advise serious
consideration before proceeding down the packaging of anything Java
related as you already indicate.

As you note, the users of Java software don't want packaged versions,
and when you combine that with the serious time commitments to even
attempt not just the initial packaging but the long term maintenance
you soon risk getting what Fedora has already seen as documented on
this list the last 6 months or so - packages being abandoned.

My reluctant policy these days is to use whatever the language
communities have set up to install anything beyond the basics, whether
it be Pip or Maven or whatever, as that just seems to be the way those
communities want things to work.

Thus I think a far better goal might be:

1) package only stuff that makes sense - ie. anything based on a
language that doesn't have its own package management system like C
based programs / libraries.

2) test - make sure that even when using Pip or others to install,
that things just work on Fedora so that anyone using or trying Fedora
gets a good experience.

3) document and promote, so that Fedora looks like a valid alternative
to the Ubuntu default that so many of these external software
developers default to.  Nicely try and get Fedora added as an
additional mention in any 3rd party documenation that assumes Ubuntu
or any other Linux distribution.
___
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

Re: Fedora 31 System-Wide Change proposal: Python means Python3

[Gerald Henriksen]

On Thu, 27 Jun 2019 16:09:58 -0400, you wrote:

>On Thu, Jun 27, 2019 at 2:52 PM Dan Book  wrote:
>>
>> As an outsider to the Python community, not having any binary or package 
>> that responds to the expected name "python" would be a disaster.
>>
>Can you expand on that? As I understand it, most things that are
>calling for "python" now are expecting that to be "python2". So when
>it becomes "python3", they'll break anyway. So why perpetuate a
>pattern that's not future-proof (for some values of "proof")?

Because it's not about what some python code expects, it about what
the human being using Fedora expects.

Nobody trying to compile a C program expects to have to use gcc9, they
just expect to type in gcc.

Similarly someone sitting down to use a tutorial to learn Python is
going to expect to type python and get something they can use,
particularly going forward when Python3 really just become Python as
Python2 fades from memory.
___
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

Re: Fedora, Packaging, Java, and Shrooms

[Gerald Henriksen]

On Thu, 11 Apr 2019 08:08:21 -0500, you wrote:

>>Secondly, isn't this what modules are meant for? I'm not sure if there is
>one for JDK on Fedora.
>
>Java 9 modules you mean? 

No, Fedora Modules, an alternative to rpms I think.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora, Packaging, Java, and Shrooms

[Gerald Henriksen]

On Fri, 12 Apr 2019 17:24:46 -0500, you wrote:

>According to pkgs.org Fedora Rawhide doesn't even have a 32-bit JRE/JDK 
>so i'm not sure why the designation is required. 32-bit has been on the 
>way out for awhile now. If someone wants to make a 32-bit version they 
>don't need to follow a distros naming convention.

According to Koji, Java is indeed still built in a 32bit version,

https://koji.fedoraproject.org/koji/buildinfo?buildID=1241271

>Fedora also packages nvidia-smi with CUDA libraries and that's wrong 
>too. On both Windows and in Ubuntu nvidia-smi comes with the driver. The 
>driver control panel is also included on both as well. nvidia-xconfig 
>comes with the driver in Ubuntu.

Fedora doesn't package nvidia-smi - the binary Nvidia driver is not
allowed in Fedora.  If you have issues with how it is packaged then
take it up with the 3rd party providers who have packaged it.

But before you do so I suggest you take a look at the packaging
guidelines to see if there might actually be a valid reason for the
way things are done...

https://docs.fedoraproject.org/en-US/packaging-guidelines/

>Because the JRE is derived from the JDK but there are use cases where 
>just having a JRE standalone is of benefit. The JRE however is being 
>killed off. Oracle no longer even distributes a JRE anymore with new 
>Java versions.

What Oracle does or doesn't do isn't relevant, as Fedora is packaging
OpenJDK from sources, and has done so from the beginning of OpenJDK.

>This specific problem(which branched out of the alternatives one) here 
>isn't with alternatives but with which the JRE and JDK are separated at 
>the package level. I'm not even sure how as an end user/developer I'd 
>even know -dlevel exists on Fedora Silverblue as dnf search doesn't 
>exist and pkgs.org doesn't bring anything up. Is there an alternative 
>for Silverblue?

If you spent some time learning Fedora, and how Fedora packages
things, or asked questions, you would learn/know that Fedora separates
out everything into a runtime package and a devel package.

Or alternatively explore koji.fedoraproject.org and see what packages
are created for each source rpm.

As for Silverblue, as mentioned it's a work in progress (and like any
open source project likely welcoming of assistance if that intersts
you).


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Fwd: Orphaned packages to be retired (Java packages in 2 weeks)]

[Gerald Henriksen]

On Mon, 18 Mar 2019 15:45:49 +, you wrote:

>
>After thinking , my suggestion is do not retire any java package.
>
>These package should be take by java sig . 

That's nice, who exactly is this Java sig you have kindly decided
should take on this significant undertaking?

My (limited) understanding is that it is the people currently involved
with Java in Fedora that are retiring all these packages so I don't
think trying to force them back onto those people is going to work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages to be retired (Java packages in 3 weeks)

[Gerald Henriksen]

On Fri, 15 Mar 2019 23:48:49 +0100, you wrote:

>* Richard W.M. Jones [15/03/2019 20:23] :

>> Is Java being dropped from the distro?
>
>Yes, that's what we were warned about months ago.

Don't think so.

Nothing has been said about dropping Java, and if anything the OpenJDK
packagers have been more active with having multiple versions of Java
now being necessary.

However a bunch of Java packages are being retired, and those packages
are required for a bunch of other packages.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: responding to CVEs

[Gerald Henriksen]

On Mon, 14 Jan 2019 13:35:10 +, you wrote:

>Is there any specific requirement to change packages in response to
>CVEs, specifically if they appear to be bogus?  I can't find anything
>specifying that.
>
>I ask because three CVEs have triggered automated bug reports against
>libxsmm .  I don't
>understand why the CVEs were issued, since a problem with unrealistic
>input to a (rather rarely used) development tool doesn't strike me as a
>security problem.
>
>On that basis I didn't bother including the upstream patch with the
>latest version, and I'm inclined to close the issues as wontfix.  Would
>that be appropriate?

I'm confused, if upstream has fixed the issue why wouldn't you apply
the fix?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What does delaying F31 mean for packagers/users?

[Gerald Henriksen]

On Thu, 29 Nov 2018 12:15:52 +, you wrote:

>From an IoT perspective where we're looking at some features around
>security that could be cross component dependent
>(toolchain/kernel/userspace) to be unable to consume for possibly an
>18 month window, yes we rebase kernels but we need to rebase other
>components and build against those, in a stable release is a complete
>and utter disaster. 

Is it specific to the F30/31 timeframe, or is it something that could
be alleviated by instead delaying to a F31/32 delay?

In other words, if the delay is necessary is there a better choice of
time to do it that would help to minimize the disruption to the
various Fedora communities?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Gerald Henriksen]

On Sun, 18 Nov 2018 17:19:37 -0500, you wrote:

>But I don't think we should extend the lifecycle on a general basis.
>That's asking for trouble, since it cedes our leadership in the Linux
>platform and destroys our ability to meet our own values.

What leadership would Fedora be ceding by extending the lifecyle?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Gerald Henriksen]

On Tue, 13 Nov 2018 18:36:38 -0500, you wrote:

>But there are some good cases for a longer lifecycle. For one thing,
>this has been a really big blocker for getting Fedora shipped on
>hardware. 

In a later message you also bring up the reluctance of Universities to
use Fedora - a bad sign given that is a good source of future
developers/packagers/testers/users.

Which thus results in perhaps another issue to consider, release
dates.

What is the best time for these manufacturers to have a release?

It has been mentioned that they would likely need a release for 6
months before releasing hardware with it, and that would likely be
similar to any organization looking to roll it out onto desktops.

So should Fedora, if it goes down this path, look at having (September
-6) as a goal, to allow for the start of the school year and then the
approaching Christmas shopping season?  Or maybe (August - 6) to allow
for back to school?

A need for an early March / late February release is perhaps just as
important a question given the changes that would require in release
planning as whether to do a LTS style release.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Gerald Henriksen]

On Fri, 16 Nov 2018 17:58:36 +0100, you wrote:

>Gerald Henriksen wrote:
>> I think the problem is that for a consumer / desktop oriented product
>> - which we seem to be talking about given that this appears to be
>> driven in part by the desire of hardware vendors - the RHEL/CentOS
>> release cycle leads to problems for several years worth of hardware
>> releases.
>> 
>> If you are a hardware vendor would you want to be releasing a laptop
>> running CentOS 7.x today, with its outdated versions of much of the
>> software (that is a value to the enterprise server market, but less so
>> consumer)?
>
>But the same goes for ANY LTS distribution!
>
>No distro is going to do LTS releases with 37 month support every 6 months. 
>It would mean supporting 7 releases at once!

Of course not, which is one of the reasons why moving to a 12 month
release cycle may be a better idea, with a sort of LTS release maybe
every 2 years.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Gerald Henriksen]

On Fri, 16 Nov 2018 00:18:35 +0100, you wrote:

>Also, I don't really understand where this need for a "fedora LTS"
>comes from. I've always thought of RHEL / CentOS as filling that role.
>I agree that there could probably be more collaboration between these
>three projects (especially CentOS and fedora), but trying to introduce
>"fedora LTS", basically as a competitor to CentOS - won't help.

I think the problem is that for a consumer / desktop oriented product
- which we seem to be talking about given that this appears to be
driven in part by the desire of hardware vendors - the RHEL/CentOS
release cycle leads to problems for several years worth of hardware
releases.

If you are a hardware vendor would you want to be releasing a laptop
running CentOS 7.x today, with its outdated versions of much of the
software (that is a value to the enterprise server market, but less so
consumer)?

>Additionally, fedora explicitly targets a rather specific audience
>("developers and makers of all kinds"). Trying to "grow" fedora by
>making it less appealing to its current core audience (which most of
>the proposals I read in this thread would seem to do), seems
>misguided.

But is Fedora targetting that audience, and if so is it doing it
sucessfully?  An awful lot of OSS seems to be developed on Ubuntu, and
thus is only supported on Ubuntu by the developers with Fedora as an
afterthought if at all.

I suspect the reality is that developers today aren't looking for a
"bleeding edge" system like Fedora but rather a system that offers a
compromise between the fast releases of Fedora and the glacial
releases of Red Hat, something that has decent current hardware
support and a reasonably up to date desktop environment - in other
words what these hardware vendors want.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Gerald Henriksen]

On Thu, 15 Nov 2018 14:38:12 +0100, you wrote:

>I understand this argument, but I think more and more desktop users
>are being trained that updates happen on a schedule they didn't choose
>and are hard to avoid.  This is how most mobile operating systems
>function. 

iOS prompts you for the yearly updates, and it can be avoided if you
really want.

macOS requires you to specifically choose the yearly update, though
they may have changed with Mojave.

Not sure about Android, but the fact that Google has had to twist
things into a knot to try and get updates out to users indicates that
upgrades to Android aren't being pushed out for the most part.

Windows is the only one forcing upgrades, and it is perhaps one of the
reasons that hardware vendors are showing more interest in Linux as
people are now more willing to consider anything other than Windows.

Really, the only place where forced upgrades are happening, are
accepted, and seem to actually work are on the application side and
that is because, demonstrated by the web browsers, frequent updates
can be done unobtrusively and reliably.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Gerald Henriksen]

On Wed, 14 Nov 2018 14:04:23 -0500, you wrote:

>From what I have talked with in the past.. 3 years is their bare
>minimum and 7 is their what we really want. It usually takes the
>vendor about 3-6 months of work to make sure the OS works on their
>hardware without major problems and then they want people to buy
>support contracts for 3-5 years where the number of problems needed in
>year 3-5 are none. [This means that they want to have Fedora N for 3-6
>months before their laptops ship with it. So you ship them a frozen
>preload before you release to public. They also want any shipped to
>'last' for the warranty cycle because trying to deal with update
>questions when N eol's in the middle costs them a lot.]

I think this is the key that needs to be thought out before figuring
out if / how Fedora can meet that need.

Does this mean they need / want a new Fedora LTS every year, 2 years,
3 years?  If they want 3 to 5 years of support, and the hardware is
released 2 years in to a LTS release, does that extend it to a 7 year
LTS?

Is that really a viable Linux desktop market given how the desktops
currently develop?

Perhaps this is a discussion that needs to be expanded from just
Fedora to also include KDE and Gnome?

>This matches the majority of laptop buyers whether they are developers
>or home users. They cycle a laptop 4 to 5 years with 7-8 looking to be
>the new average. They also don't update their OS unless it does it
>auto-magically for them.  This is where the majority of profits for
>laptop sales come from so the manufacturers aim to please this segment
>most. There isn't a large margin on laptop sales anymore

I suspect the big problem is that it requires a total rethink of what
a distribution is and how it is created.

Because if you look at Windows, which is what this idea is really
talking about, yes the users are quite happy to never upgrade the OS
but that is to a large extent based on the fact that 3 or 4 years
after purchase they can still go and buy/download the latest
application and it will install and run.

That concept doesn't work very well currently with the lock step march
of an entire distro (which is essentially the OS and applications) to
newer, incompatible versions every 6 months.

Really, to support what the hardware vendors really want (even if they
aren't clearly saying it) involves moving anything non-core-os away
from the current packaging system (so for Fedora RPMS) and to some
sort of container that will work regardless of what the underlying
system is providing.

You have to be able to at the very least keep updating Firefox (as a
prime example) for that 5 years without forcing the upgrade of half
the os in the process.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Gerald Henriksen]

On Thu, 15 Nov 2018 01:33:36 +, you wrote:

>The major OS competitor has moved to a 6 month release cadence, so that
>needs to be taken into account.

And Microsoft is experiencing troubles, and a lot of push back that
they are so far ignoring.  Not all of the troubles are necessarily
from the 6 month release cycle, but I could see them eventually
following Apple with a yearly release.

Really the one to emulate if you want to use anyone as a reference is
Apple - they do an update once a year, they don't force it, yet the
almost all users quite happily do the upgrade in a relatively short
time period.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Gerald Henriksen]

On Wed, 14 Nov 2018 06:12:11 +0100, you wrote:

>We, as a distro, just take a different approach.
>To be bleeding edge requires to have releases often.

Such a bleeding edge distro that it took 4 years for Swift to arrive,
or still trying to get rid of Python 2.

Regardless of what we think Fedora is or isn't, a look outside of
Fedora shows an overall Linux community that appears to be
increasingly ignoring Fedora.

Part of this discussion needs to be around the combined issues of
getting more maintainers and getting more users.

My feeling is part of the solution is to move to a yearly release
cycle.  Unlike the early days of Fedora things just aren't changing as
quick in terms of the base of the OS - hardware support in the kernel
is generally excellent, and both Gnome and KDE (and likely the others)
are mature environments that while they improve with each release
there isn't generally anything that says a 6 month wait would be
unbearable - and consideration should also be done to the track record
that given the overall stability of those desktops that upgrades can
likely be done safely mid-Fedora-release.

So perhaps then you go with 2 effective releases of Fedora - a one
year release, and a 3 year release.  You get the benefits for those
that need it of a LTS style product, reduce the upgrade churn that is
putting off some prospective users.  Won't satisfy everyone but it may
be an improvement.

Anything that really can't wait for a next release could be
temporarily thrown into COPR, with perhaps a feature that at the next
major release the COPR repository automatically gets removed as the
package is now available from the main Fedora repository.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: IBM buying RedHat

[Gerald Henriksen]

On Sun, 28 Oct 2018 23:39:52 +0100, you wrote:

>Le 28/10/2018 à 22:32, Neal Gompa a écrit :
>> but the point is, IBM is not an open source company.
>
>Eclipse, 

Not exactly a ringing endorsement given Eclipse's poor reputation.

>Linux (top 5 companies in term of kernel contributions), MQTT 
>(network protocol), OpenPower (hardware), etc.

All server oriented, whereas Red Hat has been server yes but a lot
more.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning some Java packages

[Gerald Henriksen]

On Fri, 28 Sep 2018 10:15:46 +0200, you wrote:

>Le jeudi 27 septembre 2018 à 19:14 -0400, Gerald Henriksen a écrit :
>> 
>> Or, short version, the Java ecosystem is either indifferent or hostile
>> to distribution packages.
>
>Any language ecosystem is initially hostile to distribution packages. 

Except this has been going on for years, and hence is long past the
initially stage.

>Besides the main advantage of distribution packages is upgrade
>management, and composing of many software components, by tracking the
>state of each of those components, and providing uniform deployment
>rules.

Which quickly falls apart when upstream refuses to update their code
to the latest versions of the libraries they use, and Fedora (rightly)
as a rule doesn't want multiple versions of libraries.

I agree that in an ideal world the distribution model is the best and
most effective, but we don't live in an ideal world and sadly many
(most?) upstreams don't follow what a distribution would consider good
practices.

>There are no special distribution-friendly langages. C?C++ software was
>deployed for years without packages on Solaris, AIX, Windows and so on
>before all the efficiency wins of doing via packages on Linux made Linux
>distributions capture that market.

Except all the "modern" languages decided to solve the problem
themselves with their own repositories of libraries and build systems
that pull in dependencies as needed.  They (somewhat rightly from
their respective) view maven, gradle, npm, etc. as the best and
preferred solution because they deal with it once and it covers every
OS.

Which is why the C++ community is belatedly dealing with the issue and
has started a working group on trying to deal with the issue of a
package manager.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning some Java packages

[Gerald Henriksen]

On Thu, 27 Sep 2018 10:34:33 -0400, you wrote:

>On Mon, Sep 24, 2018 at 3:39 PM Mikolaj Izdebski  wrote:
>>
>> Java SIG is dying slowly, this package set recently lost another
>> co-maintainer and I don't have time to maintain all these packages by
>> myself. Switching to module-only content is probably the best move to
>> keep high-quality software delivered to our users and reduce maintenance
>> work at the same time.
>
>Have you done *anything* to try to reinvigorate the Java SIG? I've not
>seen anything at all about this problem. Do Java folks in the
>ecosystem who happen to use RH/Fedora ecosystem stuff know about it?

This sort of came up a couple of years ago when the packaging of
Hadoop and other Big Data stuff was started by others.

Part of the reason it didn't go far was that the Hadoop / Big Data /
Java community didn't trust / weren't interested in using versions of
the software packaged up into rpms.  I suspect part of the reason was
that it was difficult to know what was happening (it seems like
installing anything non-minor in Java results in hundreds of rpms to
be installed) and too many Java projects don't maintain their
dependencies very well.

Or, short version, the Java ecosystem is either indifferent or hostile
to distribution packages.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: GNOME 3.30.0 megaupdate

[Gerald Henriksen]

On Thu, 06 Sep 2018 11:33:20 -0700, you wrote:

>On Thu, 2018-09-06 at 10:41 -0600, Chris Murphy wrote:
>> Fedora folks have been testing 3.29 for weeks now. Fedora people
>> haven't been testing 3.30 because it's not really available to test.
>> So I think it's reasonable for a GNOME specific change to explicitly
>> state a request and expectation for a beta freeze exception for every
>> Fedora release so that a .0 lands in the beta, and see if FESCo thinks
>> that's sane and accepts the change.
>
>Uh, to be clear here: you do know that 3.29 is the development series
>for 3.30, right? It's not a sudden major release jump. Effectively what
>we have right now is more or less 3.30 rc0-and-a-bit; the proposal is
>to go from that to 3.30 stable.

Is it though in terms of what is actually in Fedora?

The original message that started this stated:

--
We are quite a bit behind with the builds, like half of GNOME is still
at 3.28.x or at various stages of 3.29.x snapshots, so there's quite a
bit of catching up to do.
--

which isn't quite the same thing as saying its the same thing 3.30 rc0

Which would also appear to mean it will be a more intrusive and hence
risky update than it would be if Gnome has actually been at a 3.30
rc0-and-a-bit stage.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Mono - Do we have a maintainer?

[Gerald Henriksen]

On Wed, 22 Aug 2018 13:59:51 -0400, you wrote:

>* Dan Horák  [2018-08-22 03:55]:
>> a nice thing on Mono is that it is fully multi-arch, supporting all
>> Fedora arches. Won't be multi-arch problem for msbuild or .NET Core?
>
>Oh. Right, that would be a problem. .NET Core upstream essentially
>supports x86_64 only. arm-hfp, aarch64 and x86 are supported to some
>extent. Every other platform is pretty much unsupported.

As of .Net Core 2.1 Arm32 is officially supported.

https://blogs.msdn.microsoft.com/dotnet/2018/05/30/announcing-net-core-2-1/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P5KACXUM4UKXJCKVOIBXJTLHMRKWT63E/

Re: Cfitsio soname bump

[Gerald Henriksen]

On Fri, 25 May 2018 08:55:01 -0700, you wrote:

>On Fri, 2018-05-25 at 12:41 +0200, Sergio Pascual wrote:
>> Hello, I'm going to build new cfitsio 3.450 in Rawhide.  This involves a
>> soname bump. Notice that I plan to do the same in F28 (with a buildroot
>> override, etc) as cfitsio has security issues
>> https://bugzilla.redhat.com/show_bug.cgi?id=1570484
>
>Thanks for the heads-up, but this is still not in line with the policy:
>
>"When a proposed update contains an ABI or API change: notify a week in
>advance both fedora-devel and maintainers directly (using the
>packagename-owner@ alias) whose packages depend on yours to rebuild or
>offer to do these rebuilds for them."

Does that even apply for a security update, as in this case?

Seems a bit dangerous to me to announce to the world there is a
security hole in a library, but by the way we won't be fixing it for
at least a week.

Obviously ideally a security fix wouldn't require an ABI/API change,
but far too many upstreams don't follow the ideal world.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IF6D5ICOH7T2WZMYBDFIFV62H4WL2HW3/

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Gerald Henriksen]

On Tue, 10 Apr 2018 13:36:33 +0200, you wrote:

>Tomasz Torcz ?? wrote:
>>   While we at it, let's drop all latin fonts, too. Cyrillic should be
>> enable to cover most of the world's usage and is quite similar to basic
>> latin.
>
>???! ;-)
>
>But more seriously, this is not a fair comparison. 

Why should some people of the world be excluded from Fedora though?

Shouldn't the priority be to make Fedora welcoming to all, and not to
limiting the audience based on an artificial size limitation?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Gerald Henriksen]

On Thu, 29 Mar 2018 22:37:12 +0200, you wrote:

>The one thing that speaks for it is size: it is only ~4 MiB xz-compressed, 
>whereas a typical font for any single CJK language (which may or may not 
>have the same limited support as described above for the other 3 languages; 
>often, there are no characters at all for the unsupported languages) is
>20+ MiB xz-compressed. At the time where the decision to ship it on the KDE 
>Spin was made, the choice was between WQY MicroHei or no CJK support at all.

I think looking into size increases is useful, if for no other reason
than to ensure mistakes don't get overlooked.

But I also think worrying about an artificial size limit, a limit that
made sense in the past, is damaging.

In the past arguments have been made that we have to keep it small for
those with limited and/or expensive bandwidth.

While a noble goal, it is unfortunately something that is only paid
attention to when creating the live images and then immediately
forgotten.

I just started up one of my Fedora vm's, which was last updated 3 days
ago.

In 3 days I now have 50 packages to update/install with a total
download size of 171M.

So in 3 days I have accumulated downloads totally half the size
increase causing all this angst.  While certainly not perfect, it
roughly gives me 10G of updates to download and install over a 6 month
life span of a typical Fedora release.

Consult the relevant experts, and based on their recommendations
mandate a base set of fonts that provide a quality first experience
with Fedora for everyone regardless of where they live and what
language they read/write.  Making compromises to save 400M on a
distribution that will need 20+G over  year doesn't seem very wise.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Gerald Henriksen]

On Fri, 23 Mar 2018 12:57:19 -0400, you wrote:

>On 03/23/2018 07:23 AM, Petr Viktorin wrote:
>> In case no one steps up, we'd like to start dropping Python 2 support
>> from dependent packages *now*, starting with ported libraries on whose
>> python2 version nothing in Fedora depends. (We keep a list of those at
>> [1].)
>
>I'm +1 to the idea of dropping Python 2 support in general, but I'm not
>sure we should really do it gradually (which is what would effectively
>happen if some packagers start dropping now and others later, and others
>not at all). It seems to me like it'd be cleaner to have a release note
>on Fedora 30 that's just "Python 2 support dropped" and do it all at
>once. Thoughts?

It's not just all the Python 2 code that is packaged in Fedora though,
but also all the Python 2 code people are running on their machines.

By gradually (or sooner than Fedora 30) getting rid of all the
libraries and other Python 2 stuff it at least gives the option for
those people who get surprised to fix things before the Python
interpreter itself goes EOL and doesn't get security fixes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package naming question

[Gerald Henriksen]

On Mon, 04 Dec 2017 10:20:13 +0100, you wrote:

>I would like to hear opinion of other packagers about naming. We have
>`parallel` utility implemented in Rust which is drop-in replacement for GNU
>parallel. I was thinking how to name package and how people would expect it to
>be named. So far options are:
>
>* rust-parallel
>* parallel-rust
>* parallel-rs
>
>I dislike first one because it is not ending up in completion while second and
>third are quite good.

To me the second and third make it look like the package is part of
the existing parallel package - perhaps rust bindings to parallel -
and not an entirely different program.

In other words, I could see people install parallel-rust because "it
must be part of the parallel package" based on its naming and not
realize it is an entirely different program doing the same thing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 27 is officially released!

[Gerald Henriksen]

On Thu, 16 Nov 2017 08:38:43 +0100, you wrote:

>On Thu, 2017-11-16 at 15:15 +0800, Christopher Meng wrote:
>> On 11/16/17, cornel panceac  wrote:
>> > No Linux 4.14 ?
>> 
>> Are you expecting 6 years support cycle?
>
>I think in a sense, many are...?
>I know fedora is supposed to pretend rhel is "just" downstream's problem
>but I see a lot of "redhat.com" emails here and when you ask red hat
>instructors and affiliated about rhel8 they just say "ask fedora".
>Nevertheless, right now everyone's crystal ball is hinting at a rhel8
>branched out of f27 (which may be nonsense), so the question of a
>LTS kernel seems natural.

My understanding / assumption is that while each new line of RHEL is
based off of a given Fedora release, Red Hat does make tweaks /
changes to suit the needs of what they offer.

Thus, if you are correct and the hypothetical RHEL 8 is based on F27
there is no reason Red Hat wouldn't choose to use the 4.14 kernel
regardless of what is in Fedora when they decide to branch.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: apple swift fedora support

[Gerald Henriksen]

On Mon, 16 Oct 2017 12:50:01 +, you wrote:

>Is there any initiative to package apple swift and other swift tools?
>
>https://github.com/apple/swift

Attempt to package and get into Fedora can usually be found in
Bugzilla, for Swift see:

https://bugzilla.redhat.com/show_bug.cgi?id=1295115
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Gerald Henriksen]

On Sun, 15 Oct 2017 15:35:56 +0200, you wrote:

>IMHO, it would be reasonable and common sense to either postpone F27 
>until FF57 has become stable or to revert the firefox change.

Except FF57 is stable (at least no one so far is complaining about it
being otherwise).

For those who use its plugins then there may be an issue (depending on
how many do a last minute update vs. can't/won't be udated) but that
day of reckoning is coming sooner or later unless they choose to never
update Firefox again.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: A less "bloated" KDE spin

[Gerald Henriksen]

On Thu, 12 Oct 2017 05:27:39 +0200, you wrote:

>family of tools. Every regular user will choose their own tools for
>calendar, email, etc. Simple picture viewer/kpaint etc, should be included
>because they are essential part of a desktop system, however, calendar,
>address book, email client, are not.

macOS comes with calendar, address book, and I assume email.

Windows 10 comes with email, address book, and calendar.

I haven't used it in a long time but I would be surpised if Gnome
doesn't include those apps as well.

iOS comes with email, address book, calendar and I assume Android does
as well.

Thus it would be very unusual for a desktop not to include those
applications.

Yes, some users will have their own preferences.  But a surprising
number of people simply use whatever the OS/Desktop comes with.

>Now that said, it was discussed that the spin is meant to be as a showoff
>of the KDE family. Is it? Or is it meant for the *actual user* who has
>preferences.

Both I assume, with the inherent compromises that brings.

The big difference however is that the experienced user will have the
knowledge on how to customise the desktop to their liking, which a
more ordinary user who is happy to use whatever comes with the desktop
won't.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible to upload new sources of a package from a URL?

[Gerald Henriksen]

On Tue, 26 Sep 2017 07:50:11 + (UTC), you wrote:

>On 2017-09-26, Richard W.M. Jones  wrote:
>> On Tue, Sep 26, 2017 at 07:18:12AM +, Petr Pisar wrote:
>>> A packager is responsible for reviewing the code before uploading it to the
>>> Fedora infrastructure. It does not mattter whether the code matches what
>>> upstream released. Actually in some cases the code is intentionally
>>> changed by the packagers (e.g. when removing bad-licensed code).
>>
>> Are there any tools you'd like to suggest for reviewing 100GB
>> (or even 10MB) of code?
>>
>diff. First you review 100GB code, and then you review differences only.
>Actually you do not need to review 100GB of code. You can unbudle it
>first. I doubt the 100GB were written from scratch. 

That may be fine for any packagers who are actually paid to package
(though even then I would have my doubts that every line of source has
been checked), but it is clearly an impossible task in terms of time
required for all the volunteer packagers.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: A less "bloated" KDE spin

[Gerald Henriksen]

On Sun, 10 Sep 2017 23:34:10 +0200, you wrote:

>+1 for making the KDE spin lighter.
>I'm really surprised with all the advocates here. Isn't it the right way to
>go, to always have as minimal install as possible, with just the basics for
>the purpose? I truly believe that everyone grabs KDE spin for the Plasma
>desktop, for the environment, and not for all the K* packages in the world.

Yes, experienced users may well grab KDE spin for Plasma, and then
proceed to customize it to their needs and/or preferences.

But there is also the audience who are trying out KDE (or Gnome/etc)
for the first time and providing them with an installed base of
software to try / check out is convenient and the right thing to do.

While you (and others) may well know the name of the software you like
for a given task, new people will not have that knowledge.

>> # dnf remove foo
>> and you can easly get rid of what you do not like.
>
>Yes, I've installed it and removed about a *gigabyte* of. I believe
>that most people will use maybe one or two tools out of that list.

Yes, but its the age old problem that for that "most people" the 1 or
2 tools is different than the other person.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

[Gerald Henriksen]

On Fri, 28 Jul 2017 14:11:56 -0400, you wrote:

>> One of Fedora's stated goals is to remain close to the upstream.
>> Upstream Python is going to change /usr/bin/python to mean Python 3. If
>> AH keeps it on Python 2, it will be confusing for Python programmers
>> using AH. It will be especially confusing for programmers who want to
>> write software that works on "normal" Fedora and AH.

>I don't want to break Ansible users or in general random sysadmin scripts;
>the value of replacing the meaning of /usr/bin/python feels quite low relative
>to that.

Then perhaps someone should take this up with upstream and see if
upstream agrees with the issues and changes their plans?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

[Gerald Henriksen]

On Fri, 28 Jul 2017 21:06:45 +0200, you wrote:

>On Fri, Jul 28, 2017 at 10:29:12PM +1000, Nick Coghlan wrote:
>
>> It's only /usr/bin/python itself that still presents an unsolved
>> problem, since the status quo (not providing it at all) is even more
>> user hostile than pointing it at a modern version of Python 3 that
>
>Why is not providing /usr/bin/python more use hostile? Why is it better
>for any script to use /usr/bin/python instead of /usr/bin/python3?

Because any user of Fedora trying to learn Python using either books
or online sources will be told to type "python" and said user will
expect it to work.

Or they know python, use it, but don't care about the details of
versions, and so just expect to type "python" and it works because
thats what upstream decided?

And when it doesn't work, a percentage of said users will then try
another distribution or *bsd that does provide said standard of just
typing "python"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Some preliminary Fedora 25 stats — and future release scheduling

[Gerald Henriksen]

On Tue, 6 Dec 2016 09:11:06 +, you wrote:

>> I'd expect .1 or +1 would rebase on the most recent GNOME.
>
>I expect we'd also rebase the virtualization stack in any .1 release,
>or even in the middle of a release if Fedora switched to a yearly
>major release cycle. 6+ months is already a long time to wait to push
>out new features to users, so making it longer is really not helpful
>from KVM virt stack pov.

The world has changed quite a bit since Fedora was launched, and as
anyone running stuff in the non-Linux world has experienced:

1) the base OS is on a yearly cycle with minor updates between (not
just macOS and Windows 10, but iOS and Android as well).

2) many of the apps one now uses update automatically without user
intervention so you never know what version of Firefox/Chrome/etc you
are using - users have gotten used to if not actually expecting that
the software continously updates and no user attention is requied
unless it is a significat change.

>If we get lots of stuff rebasing in a .1 release though, it seems that
>the result is not dramatically different from what we're doing today
>with 6 monthly releases. 

So you restrict a .1 release to anything critical to the running of
the OS, and let the apps upgrade as they want.  This can have a couple
of influences on testing:

a) you only make 1 release a year installable, everything else is an
in place downloaded update via dnf.   Side-effect, this helps the
issue brought up elsewhere on the list about testing of physical
install discs.

b) presumably it is easier for testing to test individual apps with
major changes throughout the yearly release as opposed to cramming
everything into a short period before each 6 month release.

c) if the move to updates during a release is allowed, then it can
perhaps remove the haste in getting some applications "out the door"
in time for a Fedora alpha release, allowing more developer testing
prior to being thrown on top of Fedora (and perhaps then making it
easier to actually get Fedora released on time).

d) while there will still be some components that need to wait for an
official Fedora release - big compiler changes, incompatible
libraries, databases (maybe depending), it should hopefully reduce the
pressure to get everything into a release and thus ease the burden on
testing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

[Gerald Henriksen]

On Thu, 30 Jun 2016 22:07:24 +0200, you wrote:

>On Thu, 30 Jun 2016 15:59:38 -0400
>Solomon Peachy  wrote:
>
>> On Thu, Jun 30, 2016 at 08:04:57PM +0100, Richard W.M. Jones wrote:
>> > I will just snipe here that the situation would be better if POWER
>> > > 4 hardware was generally available to buy.
>> 
>> The upcoming Raptor Talos POWER8 board [1] looks promising, but at
>> $3700 a pop just for the motherboard and an entry-level [1] CPU, it's
>> out of reach of many otherwise-interested developers.  Assuming it
>> goes into production at all..
>
>unfortunately it does not in foreseeable future (based on official
>update on their IRC channel). It was my hope to get newer workstation
>class HW and be able to lift the ppc64 (BE) support to Power7 and up
>(or so). With the OpenPOWER ecosystem there is still chance someone
>else will try it.

I wouldn't count on it.

To get developers they need to get a CPU/motherboard combination out
for under $1000, likely closer to $500, as these will be purchases as
a secondary system to "play with" because there is no direct way to
make money as a POWER developer (this also applies to Aarch64, which
is also looking rather absent).

At least for POWER8, this would likely mean someone from OpenPOWER
would need to fund the development of a affordable POWER8 chip with no
expectation of directly recouping that cost, which seems unlikely.

Which is a shame, because with more developers/users there might be
more volunteers for Fedora such that a specific POWER8 spin would
become viable, helping to solve the current problem.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

[Gerald Henriksen]

On Thu, 30 Jun 2016 18:01:38 +0200, you wrote:

>> Realistically, it isn't about either specifically.  Each iteration of
>> POWER tends to require tuning specifically for that generation if you
>> want to get the most performance out of your software.
>
>Latest CPU features get utilized mostly only in inner loops of high
>performance code which should use IFUNC.  So building the whole distro for the
>latest CPU brings only incompatibility with no real performance advantage.

When you spend the type of money that a POWER type system costs, you
expect to get every bit of benefit you can out of that system, and
that means everything from the OS on up will be expected to be
compiled for the version of POWER you are running.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Gerald Henriksen]

On Fri, 17 Jun 2016 15:05:01 -0400, you wrote:

>I still think we, as a distribution, should not be in the business of
>discouraging downstream packaging in favor of *upstream* provided flatpaks,
>though (which was my original objection to the idea).

Which is better for the user:

1) upstream Flatpak that the user can get support from upstream if
they run into problems

2) Fedora package (either rpm or Flatpak) that upstream won't support,
so if the user runs into problems they are told to talk to Fedora,
which while I certainly appreciate the effort done by packagers they
often aren't familiar with the codebases and can't offer any help?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Gerald Henriksen]

On Thu, 16 Jun 2016 15:44:11 -0400, you wrote:

>On 06/16/2016 03:09 PM, Alexander Larsson wrote:
>> You seems to think about a different "security" than what flatpak
>> provides. Say you run a game, packaged by fedora. Its nicely packaged
>> and reviewed, so you're not running unreviewed, unsigned scripts as
>> root to install it. This is traditional "unix security".
>>
>> However, if the game talks to the network and has bug, it can still
>> easily be attacked and the resulting powned process has full access to
>> your ssh keys, your email containing private info, your gpg agent, etc,
>> etc.
>I get that, but as I said, RPM can have sandboxing too, and so far it 
>looks like the main vulnerability vector is unpatched software. Flatpack 
>wouldn't have helped with heartbleed, and the right remediation for it 
>was rapid patching---which was hampered by all the bundled SSL libraries 
>even without many containers in the mix.
>
>I do see the utility of containers, and realize that properly curated 
>containers can be patched as well as native packages. It's just that I 
>am concerned that they will diffuse responsibility for patching so much 
>that effectively curation will fail.

To me though you are talking about an ideal world where everything is
properly packaged into rpms and everybody deals with security issues
promptly.

There is a lot of evidence however that we aren't living in such an
ideal world, and as a result there is a lot of software installed
outside of rpms that rarely gets updated.

How much of this self installed software would get updated when the
next vulnerability is found (or for that matter, how much self
installed software still has old bundled SSL exposing systems)?

So while Snap / Flatpak / Docker may mean 50 different copies of a
library need to be fixed, the fact that those packagers (presumably
being as responsible as existing rpm maintainers) actually release new
fixed versions might actually mean systems will be far more secure
than currently.

Is it perfect?  No.  In fact I think the biggest problem with Flatpak
is that it is restricted to GUI apps, which might make Snap more
attractive to end users.  But it is a step in the right direction to
solving an existing problem and making systems more secure.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Gerald Henriksen]

On Wed, 15 Jun 2016 22:18:00 -0400, you wrote:

>Snaps function very much like how Apple's ecosystem does for software
>delivery, and perhaps even Microsoft's UWP ecosystem too. It's very
>clear that the purpose of Snaps are to provide avenues to "encourage"
>people to lock into the Ubuntu platform.
>
>So far, I've seen people gloss over the real crux of the problem,
>which is that somehow we're trying to create walled gardens, and no
>one wants to fix that.

No, the problem is that the developers of open source projects and
languages have viewed the strict rules around packages in a
distribution as a problem, and have worked around it.

Swift (you know, the hot new language that still isn't in Fedora), Go,
Python, Node.js, etc. have all created their own "packaging" systems
to either bypass the traditional Linux distribution or to handle
running on macOS or Windows that don't have a packaging system.

Combine this with the fact that a lot of the development (most?) is no
longer happening on Linux for various reasons, and that the dependency
chain on a lot of software is a packaging nightmare, and you have
Ubuntu (with Snap), GNOME (with Flatpak), and the server people (with
Docker) all coming up with simpler ways to try and get stuff packaged
given the lack of volunteers to even try and get stuff packaged in the
traditional way.

The current method of packaging rpms in Fedora is not working - there
are simply too many things that aren't getting packaged - and a
simpler alternative needs to be found.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Hadoop?

[Gerald Henriksen]

On Thu, 02 Jun 2016 21:03:14 +, you wrote:

>So, it would seem at some point, without me noticing (certainly my fault,
>for not paying attention enough), the Hadoop packages got orphaned and/or
>retired? in Fedora.

March 12 the packager of nc6 orphaned the packages they were
responsible for:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MS6LMFOZU2QY3TN42UT3YVT5BP2PCZQ2/

nc6 is a dependency of Hadoop, and was listed as such starting in the
April 9th Orphaned Packages email, repeated multiple times between
April 9th and now.

>What's the state of Hadoop in Fedora these days? Are there packaging
>problems?

Nothing has changed since the discussion you took part in on the Big
Data mailing list last August.

[short version for those not familiar - uncooperative upstream (lots
of old dependencies, old version of Java), too many packages involved,
lack of buy in by the users of Hadoop as they didn't trust the Fedora
packages, thus no willingness to commit continuing to fight to keep
the packages working]
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Proposal to reduce anti-bundling requirements

[Gerald Henriksen]

On Mon, 14 Sep 2015 20:38:58 +0200, you wrote:

>> There is a reason that the Atomic / CoreOS idea combined with Docker
>> is gaining traction, and it is because it deals with the reality of
>> dealing with software whose dependencies don't work in the traditional
>> distribution world
>
>so i don't live in the real world?

I never said anything otherwise.

I was pointing out that most of the software developed in the last
decade, software written in languages like Java, PHP, Ruby, Go, ...
have all been written based on using their own criteria for
dependencies.

There are a number of reasons for this less than ideal state of
affairs, but just because you don't have to deal with it doesn't mean
no one else has to.

-- 
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: Proposal to reduce anti-bundling requirements

[Gerald Henriksen]

On Mon, 14 Sep 2015 12:45:13 +0200, you wrote:

>if Fedora changes to more and more recommend "pip", "gem" and "cpan" 
>like installs instead RPM packages it is no longer a distribution over 
>the long because that would mean finally you have a core OS and handle 
>anything else like Microsoft or Apple - does anybody really want to go 
>that road?

It's not a case of whether anyone here wants to go down that road or
not, because we are already there.

There is a reason that the Atomic / CoreOS idea combined with Docker
is gaining traction, and it is because it deals with the reality of
dealing with software whose dependencies don't work in the traditional
distribution world.

-- 
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: Proposal to reduce anti-bundling requirements

[Gerald Henriksen]

On Sun, 13 Sep 2015 23:30:13 +0200, you wrote:

>On 2015-09-13, 20:23 GMT, Haïkel wrote:
>> The Java world is definitively not moving in the right direction.
>
>https://en.wikipedia.org/wiki/Java_Module_System is IMHO The 
>Right Thing™ and it is still on the list of deliverables for 
>Java 9 (still to be feature complete on 2015-12-10).

Maybe feature complete by the end of this year, but Java 9 will not be
released until this time next year (assuming no delays), which in
itself will mean nothing.

Because none of the project using Java will adopt it anytime soon.

And even when enough time passes, it still won't solve the problem of
trying to fit Java into rpm packages.

-- 
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: Heads up; F22 will require applications to ship appdata to be listed in software center

[Gerald Henriksen]

On Tue, 28 Jan 2014 16:48:50 -0500, you wrote:

>On Tue, Jan 28, 2014 at 01:40:00PM -0800, Josh Stone wrote:
>> >> If you want to install a c++ compiler you would have to know the exact
>> >> package name of that compiler. There is no way to search for something 
>> >> like
>> >> "compiler" with yum (AFAIK).
>> > "yum search compiler"
>> ... which lists a lot of packages, but neither gcc-c++ nor clang.
>> So yes, yum can search, but the metadata is limiting.
>
>So.
>
>yum search all compiler
>
>will also search package descriptions and URLs (in addition to the default
>of just package names and summaries).
>
>That includes both gcc-c++ and clang.

But what it returns can be less than helpful if you don't already have
an idea of what you need.

So for clang we get "A C language family front-end for LLVM", which to
many of us probably means C and C++ (but we may not think of
Ojbective-C), but someone new to programming may not make the
connection.

But the good news is that plain old gcc is apparently all powerful,
because according to the search gcc has "Various Compilers (C, C++,
Objective-C, Java, ...) so if I didn't know better I could just
install the gcc rpm and compile my Java code...

Or maybe they are looking for a Go compiler?  None listed in those
short descriptions - gcc-go merely says "Go support", while golang
doenn't get listed at all.  A search for Go gives a huge list, not
even sorted alphabetically, to sort through.

On the other hand, why should you need to become an expert on the
options of yum to find a compiler?  Particularly when you have a gui
program that seems to be a list of programs that are available.

Even more fun is dnf, which appears to return the list in entirely
random order.

-- 
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: Proposed F19 Feature: Cinnamon as Default Desktop

[Gerald Henriksen]

On Mon, 28 Jan 2013 12:26:14 -0500, you wrote:

>On 01/28/2013 11:56 AM, inode0 wrote:
>> What concerns me isn't that Linus and Alan don't like it.
>
>To be fair Linus (more quietly) went back to GNOME 3 after his initial
>loud complaints. He is still using it since he just posted that he was
>to G+ yesterday.

Which is likely more a statement about how poor the alternatives are
than a change of his views of Gnome 3.

While I wait to see what this new Gnome mode looks like, the choices
facing Linux users aren't great - either the desktop has gone off on
strange path (Gnome-shell), simply don't like (KDE) or lacks the
developer base to provide a suitable experience.

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

Re: *countable infinities only

[Gerald Henriksen]

On Wed, 20 Jun 2012 13:40:14 +0900, you wrote:

>> On Mon, 18 Jun 2012 14:56:20 +0100
>> Matthew Garrett  wrote:
>>
>> System76 (and possibly others) will be supplying systems 
>> that provide (2), so that choice is available to you.
>
>Matthew, I often read you referring to System76, since the UEFI
>discussion. System76 products are limited to the US market (only), and
>not all Fedora users are US residents.

They do ship to other countries, Japan included:

https://www.system76.com/home/shippinginformation/

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

Re: *countable infinities only

[Gerald Henriksen]

On Tue, 19 Jun 2012 11:15:34 -0700, you wrote:

>On Tue, 2012-06-19 at 12:03 -0400, Jay Sulzberger wrote:
>
>> Adam, just a short bald claim:
>> 
>> In the United States and Europe there is a large body of statute
>> law, regulatory rulings, and court decisions which say that yes,
>> a large powerful company cannot take certain actions to impede
>> competitors.  In particular entering into a compact to make
>> Fedora harder to install on every single x86 home computer sold
>> is not allowed.  Or once was not allowed.  Recently neither
>> regulatory bodies, nor courts, have enforced these old once
>> settled laws and regulations.
>
>I'm aware of this. So are Red Hat's lawyers, I'm sure. I am inferring
>from the stuff posted by Matthew so far that they believe there is no
>basis for a legal complaint in Microsoft's behaviour in this area. I
>certainly can't see one myself, though of course I am not a lawyer; as
>I've already noted, it's very hard to characterize Microsoft's behaviour
>as 'impeding competitors'. They have done nothing at all to prevent
>anyone else from complying with the Secure Boot specification.
>-- 

Thinking about it, I would go further and say that even if Secure Boot
could not be disabled, and 3rd parties could not get keys, would not
violate the law.

Microsoft got into trouble for 2 things - including IE as part of
Windows, and their agreements with OEMs that made them exclusively
Windows.

On the web browser, I think it is safe to say history has sided with
Microsoft.  Every OS or Desktop Environment now comes with its own web
browser, because a device connected to the Internet without a web
browser is useless for most people.

The trickier issue was their OEM agreements, which likely were a
violation of the law, which forbid the OEMs from selling products with
competing products if they wanted to sell Windows.  It is obvious that
these clauses no longer exist, as for example Dell has sometimes sold
machines with Linux.

Requiring Secure Boot for Windows 8 certification thus wouldn't be
anti-competitive, even if it could not be disabled, because Microsoft
is not forbidding anyone from producing and/or selling an x86 (or
otherwise) product without Secure Boot.  In fact, Microsoft's legal
standing is likely strengthened for the time being by the fact that if
Dell for example were to sell a machine at Christmas without Secure
Boot the machine would be able to run Windows 8 (whether Dell could
ship it with Windows 8 installed, or the end user would have to
purchase a copy and install it themselves is unknown and not
relevant), the only definite restriction is that Dell could not market
that machine as Windows 8 ready.


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

Re: *countable infinities only

[Gerald Henriksen]

On Mon, 18 Jun 2012 19:21:40 +0200, you wrote:

>
>
>Am 18.06.2012 19:18, schrieb Adam Williamson:
>
>> I hesitate to put words in people's mouths, and correct me if I'm wrong,
>> but it reads to me as if Jay and others are arguing from an incorrect
>> That premise is to assume that there is a God-given right for
>> people who own computing devices to retrofit alternative operating
>> systems onto those devices.
>> 
>> I want to put it out there that this is _not true_
>
>it is true
>
>i buy a computer
>i do not rent it
>i pay money, i own teh device after giving my money

Many things you buy come with restrictions on ownership.

If you buy a car, you accept that there are restrictions on it.  You
cannot drive it anywhere you want, you must obey certain rules when
operating it, you are forbidden from making certain modifications to
it, etc.

You buy a house, and you can't do anything you want.  You must
following building codes, community bylaws, HOH/condo rules, etc.

A computer is nothing different.  If it has limitations when you buy
it, your are implicitely accepting those limitations when you complete
the transaction.  In some cases you may be able to get around those
limitations, but it is not a right to be able to.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Gerald Henriksen]

On Mon, 18 Jun 2012 10:18:35 -0700, you wrote:

>On Mon, 2012-06-18 at 09:35 -0700, Adam Williamson wrote:

Much good stuff deleted.

>Fedora can deplore the situation; Fedora can state its support for
>computing devices which allow the user the freedom to install
>alternative operating system software, with reasoned arguments in
>support; Fedora can work together with manufacturers of computing
>devices which allow such freedom. But I believe it's true, and I think
>it's vitally important to keep in mind when debating this topic, that
>there is no way in which Fedora can possibly forcibly impose its
>position on anyone. It appears to be legally fine for companies to ship
>computers you can't (aren't intended to be able to) put other operating
>systems on; it is trivially demonstrable that some companies consider it
>desirable to do so in some markets; therefore said devices are going to
>exist. Fedora can take any one of several approaches to their existence,
>but simply deploring the fact and acting, in all respects, either as if
>such devices will magically cease to exist at some point or as if we can
>pressure them out of existence both seem to be losing strategies in all
>regards, to me. I also think any argument which seems to be rooted on
>the assumption that such devices are Wrong, Evil and/or Illegal _and
>that All-Right Thinking People Will Agree if we can only motivate them
>enough_ is doomed to fail. Zillions of people buy locked devices. They
>understand, in a vague way, just what it is they are buying. They are
>not outraged. They won't be outraged no matter how outraged we try to
>make them.

Very well said.

I think a lot of the trouble here is that people have become obsessed
with hating Microsoft for past issues, and need to move on.

If people are happy with Linux returning to its roots as a hobbyist
system where you have to consult online lists of what hardware is okay
to buy, and more importantly what to avoid buying, and then searching
for and reading through howto's to get things working, then sticking a
foot down and saying we will not participate in the secure boot issue
is a valid choice.

It just isn't a choice I would make.

For Linux in general, and Fedora in particular, to continue to have
the influence it does, where essentially all but a couple of hardware
makers have provided what is necessary for open source drivers, it is
necessary to both have developers and users in sufficient enough
numbers.

And despite what people here seem to think Microsoft is not the
biggest threat to that.  Ironically, both Microsoft and Fedora are in
the same situation where the younger generation are more interested in
Android and iOS than they are in Linux or Windows.

Making it harder for those who do have an interest in trying Linux,
who might become the next user, or better developer/packager, by not
supporting secure boot will in my opinion be self defeating in the
long run.

Secure boot is not the biggest danger, a lack of new blood into the
Linux community is.

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

Re: *countable infinities only

[Gerald Henriksen]

On Mon, 18 Jun 2012 11:23:53 -0400 (EDT), you wrote:

>
>
>On Mon, 18 Jun 2012, Gerald Henriksen  wrote:
>
>> > On Mon, 18 Jun 2012 01:09:52 -0400 (EDT), you wrote:
>> 
>> >On Mon, 18 Jun 2012, Matthew Garrett  wrote:
>> >
>> >> > On Sun, Jun 17, 2012 at 11:21:14PM -0400, Jay Sulzberger wrote:
>> >> 
>> >> > I think 50 million dollars toward buying, and properly arranging
>> >> > the UEFI, of several lots of x86 computers would indeed solve
>> >> > part of the problem you point out.
>> >> > 
>> >> > Why not?
>> >> 
>> >> Because said machines would cost more than identical hardware with 
>> >> different firmware. Sales of Linux-specific PC hardware haven't been 
>> >> massively successful so far.
>> >> 
>> >> -- 
>> >> Matthew Garrett | mj...@srcf.ucam.org
>> >
>> >Why should they cost more?
>> >
>> >And suppose they cost $20 more.  Let Red Hat pay this, and/or run
>> >an ad campaign explaining that with this motherboard, you can
>> >actually know what is running on the machine.
>> 
>> So now your solution to the problem is to have Red Hat subsidize the
>> hardware (aka lose money).   That is a good way to go out of business
>> in a hurry.
>> 
>> >ad previous lack of success of sales of GNU/Linux machines: In
>> >every case I know, Microsoft just bribed/threatened the vendor to
>> >stop selling the machines.
>> 
>> Of course it could have nothing to do with the Linux community failing
>> to provide what the customers wanted, everything has to be a
>> conspiracy.
>> 
>> >If Red Hat accedes to Microsoft's demands here, there will be no,
>> >let me repeat, no hardware that Fedora can be easily installed
>> >on.  Here is why:
>> >
>> >By your own explanation, you think that without the special key,
>> >controlled by Microsoft, Fedora would be too hard for some people
>> >to install.  OK, so you agree that Fedora must get permission
>> >from Microsoft to allow easy installs of Fedora.
>> >
>> >The game is now just about over.  What if one day, Microsoft
>> >makes it even harder to install Fedora without a Microsoft
>> >controlled key?  What if, as has already happened with ARM,
>> >Microsoft refuses to grant Fedora a special key?
>> >
>> >No.  Let Red Hat tell the truth.  Let Red Hat design a better
>> >UEFI motherboard.
>> 
>> So now the target has moved from Red Hat buying some hardware with
>> secure boot disabled to Red Hat hiring a design team (at signficant
>> cost) and developing their own motherboard.
>
>Yes.  That has always been part of one of my short list of
>suggestions.
>
>Why not?
>
>ad design team at significant cost: Yes, of course.  As has been
>mentioned, all prototype UEFIs seen by the Red Hat team have bad
>interfaces.  Why not make a better one?
>
>> 
>> It is so nice that you are so willing to spend Red Hat's money, though
>> I suspect the shareholders would have other ideas about entering into
>> the world of spending lots of money to design a motherboard that you
>> then intend to sell at a loss.
>
>Gerald, I will not respond in detail to your post.  I will say
>two things:
>
>Red Hat, before its initial public offering, arranged to lose
>money, so that the company would appear more attractive to
>investors.
>
>By the incorrect theory of business explicit in your post, every
>cost borne by Red Hat, every investment made by Red Hat, must
>necessarily result in Red Hat going broke.

I never said that.

What I said was selling hardware at a loss (ie. lose money on the
hardware sale) is not something that makes sense for a software
company like Red Hat.

There are some markets where selling at a loss makes sense - the
proverbial razor blade example - because you make up the difference
and then some in selling an add on.

But because Fedora is free, there is no way to make up the money lost
on the hardware sale.

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

Re: *countable infinities only

[Gerald Henriksen]

On Mon, 18 Jun 2012 11:54:20 -0400 (EDT), you wrote:

>
>
>On Mon, 18 Jun 2012, Matthew Garrett  wrote:
>
>> > On Mon, Jun 18, 2012 at 11:03:23AM -0400, Jay Sulzberger wrote:
>> 
>> > This I do not understand.  By reports in the admittedly
>> > incompetent magazines dealing with home computers, Microsoft's
>> > policy is to keep Fedora, and any other OSes, except for
>> > Microsoft OSes, off all Microsoft Certified ARM devices.
>> 
>> I think you've answered your own question there.
>> 
>> > Further questions ad ARM: According to Microsoft, can, in future,
>> > "SecureBoot" be disabled on Microsoft Certified ARM devices?
>> > Will the person who walks out of the store with a Microsoft
>> > Certified ARM device be able to put their own signing key in?
>> > What about the PK?
>> 
>> No, Windows 8 ARM devices will not permit the user to install their own 
>> keys or disable secure boot. That's why we're not going to support them.
>> 
>> -- 
>> Matthew Garrett | mj...@srcf.ucam.org
>
>Thanks, Matthew.
>
>Just one word before I break off, if I can ;), engagement for today:
>
>If I understand correctly, Fedora has now formally allowed
>Microsoft to lock Fedora out of many coming ARM devices.

Fedora (or any other Linux) won't run on most of the ARM devices out
there already, so what is your point?

Apple certainly isn't allowing Fedora to run on the iPad or iPhone.

Samsung isn't allow Fedora to run on their tablets.

And even if they didn't prevent it, there is no open source drivers
for much of the hardware in those devices anyway, and no documentation
to write any.

The only place Linux like Fedora can run on ARM are a handful of
developer devices like BeagleBoard, PandaBoard, Raspberry PI, etc. and
even that will often require a binary blob.

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

Re: *countable infinities only

[Gerald Henriksen]

On Mon, 18 Jun 2012 11:14:11 -0400 (EDT), you wrote:

>
>
>On Mon, 18 Jun 2012, Matthew Garrett  wrote:
>
>> > On Mon, Jun 18, 2012 at 12:56:54AM -0400, Jay Sulzberger wrote:
>> > 
>> > We just need hardware we can install Fedora on, as once we did,
>> > without asking Microsoft for permission.
>> 
>> System76 have committed to providing hardware without pre-enabled secure 
>> boot.
>> 
>> -- 
>> Matthew Garrett | mj...@srcf.ucam.org
>
>Matthew, I am delighted to hear this.
>
>Note that this contradicts the claim, made more than once in
>this thread, that such an arrangement is, in practice, impossible.

No one said it was impossible.

What was said was the big outfits, who rely on selling hardware in big
volumes, will ship with secure boot enabled.  Dell, HP, Asus, Acer,
etc all rely on the Windows market to stay in business and thus cannot
ship with secure boot disabled.

But also note that is the ability to disable secure boot that
Fedora/Red Hat got from Microsoft that will allow small builders like
System76 to ship systems without it enabled.



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

Re: *countable infinities only

[Gerald Henriksen]

On Mon, 18 Jun 2012 01:09:52 -0400 (EDT), you wrote:

>On Mon, 18 Jun 2012, Matthew Garrett  wrote:
>
>> > On Sun, Jun 17, 2012 at 11:21:14PM -0400, Jay Sulzberger wrote:
>> 
>> > I think 50 million dollars toward buying, and properly arranging
>> > the UEFI, of several lots of x86 computers would indeed solve
>> > part of the problem you point out.
>> > 
>> > Why not?
>> 
>> Because said machines would cost more than identical hardware with 
>> different firmware. Sales of Linux-specific PC hardware haven't been 
>> massively successful so far.
>> 
>> -- 
>> Matthew Garrett | mj...@srcf.ucam.org
>
>Why should they cost more?
>
>And suppose they cost $20 more.  Let Red Hat pay this, and/or run
>an ad campaign explaining that with this motherboard, you can
>actually know what is running on the machine.

So now your solution to the problem is to have Red Hat subsidize the
hardware (aka lose money).   That is a good way to go out of business
in a hurry.

>ad previous lack of success of sales of GNU/Linux machines: In
>every case I know, Microsoft just bribed/threatened the vendor to
>stop selling the machines.

Of course it could have nothing to do with the Linux community failing
to provide what the customers wanted, everything has to be a
conspiracy.

>If Red Hat accedes to Microsoft's demands here, there will be no,
>let me repeat, no hardware that Fedora can be easily installed
>on.  Here is why:
>
>By your own explanation, you think that without the special key,
>controlled by Microsoft, Fedora would be too hard for some people
>to install.  OK, so you agree that Fedora must get permission
>from Microsoft to allow easy installs of Fedora.
>
>The game is now just about over.  What if one day, Microsoft
>makes it even harder to install Fedora without a Microsoft
>controlled key?  What if, as has already happened with ARM,
>Microsoft refuses to grant Fedora a special key?
>
>No.  Let Red Hat tell the truth.  Let Red Hat design a better
>UEFI motherboard.

So now the target has moved from Red Hat buying some hardware with
secure boot disabled to Red Hat hiring a design team (at signficant
cost) and developing their own motherboard.

It is so nice that you are so willing to spend Red Hat's money, though
I suspect the shareholders would have other ideas about entering into
the world of spending lots of money to design a motherboard that you
then intend to sell at a loss.



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

Re: *countable infinities only

[Gerald Henriksen]

On Mon, 18 Jun 2012 00:09:37 -0400 (EDT), you wrote:

>
>
>On Sun, 17 Jun 2012, Kevin Fenzi  wrote:
>
>> On Sun, 17 Jun 2012 23:21:14 -0400 (EDT)
>> Jay Sulzberger  wrote:
>>
>>> I think 50 million dollars toward buying, and properly arranging
>>> the UEFI, of several lots of x86 computers would indeed solve
>>> part of the problem you point out.
>>>
>>> Why not?
>>
>> Why? 50million dollars is a big order, but I don't see how this would
>> change MicroSoft's mind, or the vendors who still wish to sell Windows
>> 8 client certified systems.
>
>It is hard to answer this so direct declaration of hopelessness.
>
>Look, once Project GNU and the Linux kernel did not exist.
>
>The present situation where GNU/Linux systems are installed on
>many million machines did not suddenly happen from one day to the
>next.  There was no midnight such that one minute before midnight
>no GNU/Linux OSes ran, and one minute after, millions ran.
>
>Your framing of the issue here is ridiculous.  The issue is not
>whether we can stop by tomorrow morning every hardware vendor on
>Earth from doing business with Microsoft.  No the issue is:
>
>   Must we aid and abet Microsoft in the Microsoft campaign to
>   extinguish free sofware.

No, the issue is how do we make it easy for people to try and/or
install Fedora after the new hardware ships.

Microsoft has bigger threats than Linux to worry about these days (if
Microsoft wanted to kill Linux they would not have compromised on
secure boot).

>> Out of curiosity, what would be different about these machines you
>> propose?
>>
>> Secure boot off by default?
>> Secure boot completely removed?
>
>We write the code for the UEFI.  Our interface is better, and our
>facilities offer better choices.

People don't buy hardware for the BIOS or UEFI, they buy it based on
price and feature offered (processor, PCI slots, etc).

There is no way for Red Hat to offer the variety of hardware required.

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

Re: *countable infinities only

[Gerald Henriksen]

On Sun, 17 Jun 2012 23:21:14 -0400 (EDT), you wrote:

>
>
>On Mon, 18 Jun 2012, Matthew Garrett  wrote:
>
>> > On Sun, Jun 17, 2012 at 07:54:17PM -0400, Seth Johnson wrote:
>> > On Sat, Jun 16, 2012 at 7:26 PM, Reindl Harald  
>> > wrote:
>> > >
>> > >
>> > > Am 17.06.2012 01:14, schrieb Chris Murphy:
>> > >> Please provide an example of a better option, with sufficient detail as 
>> > >> to constitute a successful relay of the baton.
>> > >> The point of the thread from the outset was to explore alternatives, 
>> > >> but so far those alternatives are vaporware.
>> > 
>> > 
>> > Numerous non-vaporware recommendations follow, snipped directly from the 
>> > thread:
>> 
>> (snip)
>> 
>> These suggestions boil down to:
>> 
>> 1) Do nothing
>> 2) Become a hardware vendor
>> 3) Use a Fedora key
>> 
>> None of these solve the problem of getting Fedora onto arbitrary x86 
>> hardware bought towards the end of this year.
>> 
>> -- 
>> Matthew Garrett | mj...@srcf.ucam.org
>
>I think 50 million dollars toward buying, and properly arranging
>the UEFI, of several lots of x86 computers would indeed solve
>part of the problem you point out.
>
>Why not?

Intel just launched their Ivy Bridge processors, which has resulted in
likely more than 200 different products being released (combined
motherboards and systems from vendors like Dell).

Then add all the other older Intel processors that will be used in
Windows 8 certified hardware.

Don't forgot to add in products based on AMD processors.

Now factor in the customizations that can be done to many of those
products, and you can quickly see that there is no way Red Hat can
hope to offer hardware that would make every Linux user happy.

Not to mention that you are effectively telling anyone not currently
using "Red Hat Hardware" that they can't run Linux, thus eliminating
the ability to gain new Linux users.

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

Re: *countable infinities only

[Gerald Henriksen]

On Sun, 17 Jun 2012 22:01:53 -0400, you wrote:

>On Sun, Jun 17, 2012 at 8:09 PM, Matthew Garrett  wrote:
>> On Sun, Jun 17, 2012 at 07:54:17PM -0400, Seth Johnson wrote:
>>> On Sat, Jun 16, 2012 at 7:26 PM, Reindl Harald  
>>> wrote:
>>> >
>>> >
>>> > Am 17.06.2012 01:14, schrieb Chris Murphy:
>>> >> Please provide an example of a better option, with sufficient detail as 
>>> >> to constitute a successful relay of the baton.
>>> >> The point of the thread from the outset was to explore alternatives, but 
>>> >> so far those alternatives are vaporware.
>>>
>>>
>>> Numerous non-vaporware recommendations follow, snipped directly from the 
>>> thread:
>>
>> (snip)
>>
>> These suggestions boil down to:
>>
>> 1) Do nothing
>> 2) Become a hardware vendor
>> 3) Use a Fedora key
>>
>> None of these solve the problem of getting Fedora onto arbitrary x86
>> hardware bought towards the end of this year.
>
>
>Which one is the "do nothing" alternative?

Most of them.

As much as the proposed solution may suck to some, none of the
suggestions made in this thread are serious.

Vague ideas about protests will do nothing because the public doesn't
care (and this has nothing do with this specifically, protests in
general accomplish nothing most of the time).

Ideas of legal action are doomed because it will take far too long and
too much money, and likely fail anyway.  The idea the DOJ may take an
interest is a joke given the current political climate.

Come some point this fall all new hardware will come with secure boot
enabled, because none of the vendors can afford to not have the
Windows 8 certification on their products.  There is nothing Red Hat,
Fedora, or anyone else in the Linux community can do to prevent this.

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

Re: gimp

[Gerald Henriksen]

On Wed, 24 Aug 2011 13:41:41 +0200, you wrote:

>Nicu Buculei wrote:
>> And we the people using it for real work still remember the times when
>> Fedora used to be a bleeding edge distro and had such GIMP updated...
>
>+1
>
>The new update strategy (because it IS new, contrary to what some lazy 
>maintainers who always refused to follow the old policy out of sheer 
>laziness are claiming) just makes no sense, is the exact opposite of what 
>more than ? of our users are asking for (see the FedoraForum poll on the 
>subject, made prior to the change) and is destroying what used to be a major 
>selling point for Fedora.

In addition to the warning that Gimp 2.7.* is considered unstable and
not to be used in production (aka in a distribution), it comes with a
warning that they are cleaning up the API's and thus 3rd party plugins
and scripts can be broken.

So you are saying Fedora should go against the wishes of the Gimp
developers, as well as endure the significant risk that
plugins/scripts that users rely on may not work?

>It is also utterly ridiculous and pointless if you consider the fact that 
>the Firefox maintainers are allowed to push major (first digit! Not minor 
>like 2.6 to 2.8) version increments as "security" updates… (Ironically, 
>Firefox used to be one of those odd packages NOT doing feature upgrades when 
>the rest of the distro was getting them. They seem to have fun always doing 
>the exact opposite of Fedora policy.)

It's not the Firefox maintainers, it is Mozilla who have decided that
release numbers are irrelevant and that the bug fix release for
Firefox 5 is Firefox 6.

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

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Gerald Henriksen]

On Sat, 2 Oct 2010 20:56:21 -0400, you wrote:

>Fedora is just going to end up having a million repos for all the
>software that will not be updated for six months. And that makes us
>look silly. Windows doesn't have repositories for users who want the
>latest firefox, they just download it and install it. 

How exactly is the Windows experience different?

Windows - explicity download from mozilla (aka repository) and
install.

Your example Fedora - download from special Firefox repository and
install

Seems the same to me.

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

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Gerald Henriksen]

On Fri, 1 Oct 2010 08:35:45 -0400, you wrote:

>The user has to tolerate some change. We can't cater to people who
>never upgrade which seems to be what is taking place. Especially with
>the fact that our end of life happens sooner, users must already
>expect a constant stream of updates. 

Yes, running a Linux distribution like Fedora involves change - but
that change can be made manageable by only requiring disruptive
changes every 6 months (if the user follows each release) or 12 months
if the user is alternating releases.

>If they want more stability they
>should be using RHEL, CentOS or Scientific Linux, Debian Stable,
>Ubuntu LTS which do put the focus on non disruptiveness.

Are you really saying that a KDE user should be stuck with KDE 3.5.4
(which is what is in CentOS 5) if they want some stability?

Those versions of Linux have their place, but using them on the
desktop can be problematic given the rate of change in the Linux
desktop environments.  There is simply too much desktop software that
requires newer versions of libraries than are shipped with the long
term releases.

Which is why a more stable Fedora is desired.

>Each release of KDE comes with bug fixes, security fixes and new
>features.

True of most software.

> Plus combine the fact that KDE right now is evolving at a
>rapid rate thanks to all of the new developers that the 4.x series has
>attracted.

All the more reason to restrict disruptive updates to a new Fedora
release.

Certainly as a prospective KDE user (I have not liked the new
gnome-shell the couple of times I have tried it in the past) I expect
the KDE included with Fedora to allow me to do what I need to do with
the least amount of disruption possible.  While I appreciate new
versions of software that brings new features, I don't want that to
occur when I am trying to get other things done.

> Not having the latest makes it difficult for a KDE
>developer to test their stuff and make sure it keeps working with the
>latest KDE. Fedora isn't just a home to Gnome development, which as a
>framework never seems to change so they won't have the same opinion as
>the KDE people.

I hate to disappoint you but no distribution, and this includes
rawhide, is great for bleeding edge.  Like it or not but if you as a
developer need the absolute latest in development version of something
you need to package or otherwise compile it yourself.  This is why
developers working on Gnome itself use jhbuild, to automate this for
them, because the distributions themselves can't do it.  Given that
you have researched how other distributions handle KDE, it is apparent
the same is true for developers working on KDE.

Look, I realise you are passionate about KDE, and want the best KDE
experience in Fedora.  But most people are not developers, they
instead are using their desktop environment of choice to get regular,
everyday things done with office software, web browsers, email, and
sometime even custom software.  They want predictability, which means
only having to make changes to how they do things when they are
prepared for the changes, which occurs when they upgrade Fedora.  Thus
the best KDE experience you can give them is one of stability, where
KDE helps them do their work instead of being work.

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

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Gerald Henriksen]

On Sun, 26 Sep 2010 15:33:25 +0200, you wrote:

>On Sun, Sep 26, 2010 at 3:21 PM, Gerald Henriksen  wrote:
>> On Sun, 26 Sep 2010 13:41:38 +0200, you wrote:
>>
>>>On Sat, Sep 25, 2010 at 10:02 PM, Kevin Fenzi  wrote:
>>>> On Sat, 25 Sep 2010 15:53:49 -0400
>>>> Brandon Lozza  wrote:
>>>>
>>>>> It would be nice to list it somewhere as an exception, to avoid
>>>>> panics :)
>>>>
>>>> Well, I personally do not want to say:
>>>>
>>>> "Hey, anytime you like down the road, you get an exception to push a
>>>> new major version. Have fun".
>>>
>>>Well, reading FESCo meeting, it was that we're allowed to do one major
>>>update to Fn due to the different release-cycles of Fedora and KDE.
>>>Bad enough that we need "exceptions" to do our expected work and be
>>>able to be the working official KDE part of Fedora.
>>
>> Perhaps then you should approach KDE and ask them why they are so
>> distribution unfriendly with their release schedule.
>
>Why should they align the releases more with Fedora? Because Fedora is
>the #1 KDE distro? Think about it. KDE isn't distribution unfriendly.
>Fedora lately becomes KDE unfriendly. *Please* stop to rant, all the
>ranting becomes old quickly.

Perhaps you should read the part of my message you deleted, I never
said they should align their release with Fedora.

What I said was that KDE specifically goes out of their way to make it
difficult for the distributions to get the latest KDE release to the
KDE users by using a schedule that does not fit with *any* of the big
three distributions.

If the KDE project is concerned about getting their releases out to
their users in a timely manner then they should time their releases to
suit a distribution - whether it be openSUSE, Ubuntu, Fedora, or any
other distribution that makes them happy.

What does matter to Fedora is having an updates policy that is
designed to minimize disruption to users during a release is pointless
if a significant part of Fedora - KDE - is going to be allowed to
ignore the updates policy and deliberately introduce visible to the
user changes in the middle of a release.

How can Fedora market itself to potential users as a stable choice,
but at the same time warn that if you use either KDE or any of its
included programs then you can expect changes?

It can't.

And we already have proof of this with the message from the user who
won't update when a new version of Fedora is released, but instead
will wait until after the disruptive KDE update to (in his own words)
"avoid having important programs change under my feet when I'm not
prepared".

The updates policy has to be consistent across all of the projects
that make up Fedora, both to allow a consistent message to the users
(both current and prospective) of Fedora as well as to be fair to all
of the projects.

Do I want Fedora to change to bring some sanity to updates and stop
disruptive changes mid-release?  Yes.  But if FESCO, the Board, etc.
feels that allowing KDE or any other project to make changes
mid-release is important then fine, but just be consistent with the
message and treat all of the projects equally.

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

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Gerald Henriksen]

On Sun, 26 Sep 2010 13:41:38 +0200, you wrote:

>On Sat, Sep 25, 2010 at 10:02 PM, Kevin Fenzi  wrote:
>> On Sat, 25 Sep 2010 15:53:49 -0400
>> Brandon Lozza  wrote:
>>
>>> It would be nice to list it somewhere as an exception, to avoid
>>> panics :)
>>
>> Well, I personally do not want to say:
>>
>> "Hey, anytime you like down the road, you get an exception to push a
>> new major version. Have fun".
>
>Well, reading FESCo meeting, it was that we're allowed to do one major
>update to Fn due to the different release-cycles of Fedora and KDE.
>Bad enough that we need "exceptions" to do our expected work and be
>able to be the working official KDE part of Fedora.

Perhaps then you should approach KDE and ask them why they are so
distribution unfriendly with their release schedule.

As far as I can tell (based on the 4.5 release date, scheduled 4.6
release date, and the general objections raised by the Fedora KDE
people) KDE is following a 6 month schedule, but timed such as it
falls in the middle of the releases of the major biannual
distributions, and doesn't fit the 8-month schedule of openSUSE at
all.

If KDE really wants to get their latest and greatest into the hands of
their users as soon as possible then they should be more distribution
friendly.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Gerald Henriksen]

On Sat, 25 Sep 2010 22:26:46 -0400, you wrote:

>I can't tell people Fedora is the best if it's not carrying the latest
>upstream KDE, its just not possible. I'm constantly recruiting new
>users. I'm in regular contact with the team of people who run
>Techrights.
>
>If a new release of KDE comes out, this is what happens currently
>
>1) Kubuntu adds a backports PPA. Stable users do not get the latest KDE.
>2) openSUSE will have it in their KDE Factory Repo, and it will turn
>into a release Repo later (not stable). Stable users do not get the
>latest KDE.
>3) Mandriva will have official packages on kde.org but they aren't
>pushed as updates. Stable users do not get the latest KDE.
>4) Fedora will have it entirely unofficially as a third party repo for
>a few weeks, it will also be in the official repo in updates-testing
>and then in updates. Stable users DO get the latest KDE.
>
>This makes Fedora BETTER than the rest.

For your particular definition of better, which does not necessarily
agree with anyone elses defintion of better.

> If we delegate the latest KDE
>to backports like everyone else, how does that make Fedora better? And
>we do want to be better than everyone else if we want to compete with
>Apple and Microsoft.

How does shipping out possiblity disruptive changes mid-release help
us compete with anyone else?  Or make us better than anyone else?

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

Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)

[Gerald Henriksen]

On Thu, 23 Sep 2010 08:34:06 +0200, you wrote:

>Le mercredi 22 septembre 2010 à 21:30 -0400, Gerald Henriksen a écrit :
>
>> After all Gnome 2.32 isn't released until later this month, and the
>> beta releases have been included in Fedora 14 up to now.
>
>Is that a good example ? Gnome has been broken one way or another in
>Fedora 14 since branching point (I'm missing the *stable* GNOME
>experience I had in rawhide). The desktop team usually handles
>alpha/beta well, but this time they've overshot imho.

Well, Gnome has a proven track record and this release seems to be the
exception.  In fairness to the desktop team, who seem to have been
given a mess with the delay of Gnome 3, I think Gnome should have
skpped the 2.32 release rather than this attempt to get something
newish just to meet a schedule.  It's unfortunate that the desktop
team will get blamed for what is a Gnome mistake.

But the broader point is what criteria is used to determine what
software gets included in a given release of Fedora.  A key point in
the drive to have stable releases is that it is only a "6 month" wait
to get a newer version of something into Fedora.  But there is a
danger that this can go too far and end up being 9 or 10 months if a
project must have a final release before Fedora branches.

Someone wanting the latest PostgreSQL is looking at an 8 month wait
(assuming a May Fedora 15), and anything that was released in August
but not included in the Fedora 14 branch has 9 months if we don't
allow pre-releases.



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

Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)

[Gerald Henriksen]

On Wed, 22 Sep 2010 19:33:22 + (UTC), you wrote:

>On Wed, 22 Sep 2010 09:33:47 -0500, Bruno Wolff III wrote:
>> That is what branched releases have. Running one of these still gets you
>> pretty up to date stuff, but a bit more protection from breakage.
>
>But branched releases stabilize sometime before the beta point is 
>reached, which triggered off this huge discussion in the first place, 
>because Postgresql 9.0 came out too late for inclusion.

But did Postgresql 9 come out too late?

PostgreSQL had a 2nd beta release on June 4th, which could have gone
into Rawhide, and hence allowed PostgreSQL 9 to be in Fedora 14
(assuming that the packager had time to do it, and confidence that the
PostgreSQL final release would have been in time).

After all Gnome 2.32 isn't released until later this month, and the
beta releases have been included in Fedora 14 up to now.

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

Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)

[Gerald Henriksen]

On Tue, 21 Sep 2010 10:59:06 -0400, you wrote:

>However, if for example Microsoft had a similar system and did package
>software for it. Their users would be up in arms for the latest
>firefox too and Microsoft wouldn't keep them on an old firefox
>version.

You are ignoring the troubles Microsoft has had in trying to get its
users to update IE.

> Where is the logic in NOT having the latest software as long
>as it doesn't break file format compatibility? On windows the user can

I think it wonderful that you always want the latest software, but
just ask that you consider the view of other people who are trying to
get their job done.

Many of the people using Fedora are using it as a tool to get their
normal work done.  While file format compatibility is one issue,
anything that disrupts their ability to get their job done should be
avoided mid-release.  This can be a changing in the GUI layout, the
ability of plugins to work, or a new version having more bugs.

>Look at openSUSE, GCC 4.5, came out before F13, no banning of LTO. If

The decision on gcc would have to have been made around January, to
allow time for any bugs to be worked out both in gcc and in any
software included in Fedora 13.  I would assume that the gcc
maintainers felt it wasn't ready at that time, plus most of the useful
stuff had already been backported by them into the Fedora version of
gcc 4.4.

As far as LTO, the Fedora gcc maintainers have decided that it is not
yet stable and ready to be used.  The fact that you don't believe the
issues with LTO are important, or that openSUSE doesn't, isn't
relevant to Fedora.  What is relevant is that the Fedora expert(s) on
gcc have decided that it isn't ready for use yet.

>you want something better than stable for KDE you can one click
>install the factory KDE repo. You can one click install the trunk repo
>too. They even have two Chromium branches available for single click
>install (version 6 and 7). Perhaps a single click or easy method of
>installing a yum repo could be invented that is similar to the one in
>openSUSE. That would be a good start.

Like anything else, if it is important to you then you can work on
implementing it.  Fedora is limited in what can be done by what the
volunteers doing the work actually do.

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

Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)

[Gerald Henriksen]

On Tue, 21 Sep 2010 10:20:05 -0400, you wrote:

>One thing I wanted to point out. Windows users get to install the
>latest Firefox, KDE, and other apps without having to wait for a new
>Windows release. If users had to wait for Windows 8 to get the latest
>Firefox, things would be messy. I don't understand what the fear is of
>doing this on GNU/Linux.

The key point of your example is that they have to actually make the
effort to go to the appropriate website (or store to buy a physical
disc), and specifically install what they want.  It doesn't magically
appear when they allow Windows to do an update.

You can do the same thing on Fedora, you can if you so wish go to the
mozilla website and download the latest Firefox.

The problem facing Fedora, and Linux in general, is the distributions
blur the difference between the OS and apps by providing both.  But
unless you want to encourage users to not apply security updates or
bug fixes you can't combine doing updates with upgrades.

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

Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)

[Gerald Henriksen]

On Tue, 21 Sep 2010 00:36:46 -0400, you wrote:

>On Tue, Sep 21, 2010 at 12:29 AM, Gerald Henriksen  wrote:
>> On Mon, 20 Sep 2010 21:58:53 -0400, you wrote:
>>
>>>2010/9/20 Micha? Piotrowski :
>>>> Ok, so maybe it's time to setup Fedora "backports" repo for these that
>>>> wants new and shiny Firefox 4, PostgreSQL 9 or whatever with big
>>>> number.
>>>
>>>What exactly is the fear here with these updates? Are there many
>>>desktop users who do NOT want the latest released Firefox? Are there
>>>many people using Fedora as their OS for their database server?
>>
>> What if you are using a Firefox extension that hasn't been ported to
>> the latest release yet?
>
>You don't update Firefox till the extension comes out.

And if there is a security update required that makes updating Firefox
mandatory, what then?  Fedora wouldn't be packaging the latest Firefox
3.* because under you scenario Firefox is at version 4.

>Sure, but I thought Fedora was all about pushing new, free software.

It is, in two ways.  One, Fedora makes releases every 6 months where
new software can debut without worrrying about backwards
compatibility.  Secondly, for those more adventurous, you can run
Rawhide which (subject to the packagers) can always have the just
released versions.

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

Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)

[Gerald Henriksen]

On Mon, 20 Sep 2010 21:58:53 -0400, you wrote:

>2010/9/20 Micha? Piotrowski :
>> Ok, so maybe it's time to setup Fedora "backports" repo for these that
>> wants new and shiny Firefox 4, PostgreSQL 9 or whatever with big
>> number.
>
>What exactly is the fear here with these updates? Are there many
>desktop users who do NOT want the latest released Firefox? Are there
>many people using Fedora as their OS for their database server?

What if you are using a Firefox extension that hasn't been ported to
the latest release yet? 

What if you have decided that Fedora is an easier path to a server
rather than attempting to backport a lot of packages because the
current release of RHEL/CentOS is 3 years old and doesn't have what
you need in term of framework or language?

What if you are a college that has deployed Fedora to use for your
students coursework, and an upgrade to a language/database/etc breaks
things mid-semester?

Fedora is used in a lot of different ways.

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

Re: PostgreSQL 9 for F14?

[Gerald Henriksen]

On Mon, 20 Sep 2010 19:26:53 -0400, you wrote:

>On Mon, Sep 20, 2010 at 5:59 PM, Michel Alexandre Salim
> wrote:
>> On Mon, 20 Sep 2010 15:13:42 -0500, Michael Cronenworth wrote:
>>> No, I'm not advocating PgSQL 9 for F14, however, it shouldn't be so
>>> far-fetched that Fedora could have any software at any time.
>>
>> A Fedora update policy is being hashed out, and even before that, the
>> consensus is really against introducing major updates in stable releases.
>> It's not really "anything goes" as your statement seems to imply.
>
>A parallel update is a major update requiring a 6 month wait in Fedora now?

I would guess that the PostgreSQL maintainer(s) would prefer to only
maintain one version in Fedora at a time.

Really though, if people wanted PostgreSQL 9 in Fedora 14 they should
have started asking about it or working on it months ago, getting it
into Rawhide before the Fedora 14 split.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedora mission (was Re: systemd and changes)

[Gerald Henriksen]

On Mon, 30 Aug 2010 23:11:06 +0200, you wrote:

>A typical developer wants the dependencies of the software they are
>working on to be _very_ up to date - probably not the upstream
>development version, but the upstream maintenance version with _all_
>current bug fixes.  Waiting 6 months for a bug fix does not make sense -
>at that point the developer would be tempted to build the new version
>locally.

While I admit I haven't followed things very closely, I don't believe
anyone is saying don't issue bugfixes.  What is being said is don't
upgrade versions just because something newer and shinier comes along
in the middle of a release.

So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a
bug fix, but 1.6 to 1.8 is not okay because it is a new release.

>So, web developers want latest httpd/PHP/Rails/MySQL; GNOME developers
>want latest gtk/libgnome*; and so on.

I wouldn't be so sure about that.

If I was developing a web application I would want my version of
httpd/PHP/Rails/MySQL to remain stable - the last thing I want is a
bug to appear in the application I am writing and have to wonder if it
is a problem with my code or did the update in my framework change
something on me.

Similarly, if I develop a desktop app then I want gtk and the Gnome
libraries (or Qt and the KDE libraries) to remain stable under me so I
don't have to wonder where the errors are coming from.

If on the other hand I am actually developing Gnome, then yes I want
the latest gtk etc., but that is why a project like Gnome has jhbuild
to make it easy for the developers to keep to the bleeding edge of the
Gnome stack without disturbing everyone else.

>Similarly, everyone who cares about the tools they use daily (which
>developers tend to), wants the best versions of these tools, as soon as
>it is practical.  So, newest version of emacs/vim/kdevelop/...

Again, as a developer I would disagree.  Unless the latest
emacs/vim/debugger etc. offer a new feature that is going to save me
time I want things to remain consistent.  Upgrading brings the risk of
a new bug that interupts my ability to work.  This is something that
should only be done at a new release, so there are no unexpected
surprises to me as I try to balance keeping my system secure with bug
fixes and actually getting the work I want to do done.

>Saying "use rawhide" is not helpful, because rawhide is very often
>broken.  A "stable" release that breaks a specific component for a few
>days is acceptable - if this is not a component one uses for
>development, it doesn't matter; if this is such a component, one knows
>about it well enough to be able to revert an update or to contribute a
>fix.

Ironically you have actually just described rawhide.  Despite the
reputation rawhide very rarely breaks for more than a day or 2 at a
time, the usual issue is more that upgrades won't happen because of
dependency issues that can take a while to sort out.  But those don't
make the system unusable.

>When a large number of Fedora contributions are not paid to do so, they
>naturally write a distribution _for themselves_.  Why would they not?
>
>That means that updates will be frequent; few maintainers would push
>updates they consider too risky, but some risk is acceptable.  The
>"updates firehose" for components one does not much care about is a
>minor risk, compared to the "commit firehose" for a mid-size program on
>which one collaborates with two or more other people.

The problem is there is too much to a system that you do care about,
whether it be your desktop environment, an email program, X, the
kernel, etc. that end up getting pulled out from underneath you as you
try to do your work that isn't related to them.

>The result is a distribution on which it is reasonably easy to develop
>current software, and a distribution on which one might not update
>critical system updates on the night before giving a presentation on a
>conference (FWIW, I can't recall a really bad updates experience).  That
>doesn't seem to be a bad tradeoff - for a developer.

So lets see, you are going to give a presentation or attend a
conference, where you will likely be using an unsecured network with
many threats that likely don't exist in your home or office
environment, and you are saying that because we have a distrubition
where anything can change and possibly break things you think it is
okay that you have to forgo critical system updates that might prevent
your system from being hacked?  How can that be viewed as an
acceptable tradeoff?

>What Fedora advertised is "..., Features, First" - that's a developer's 
>distro; Fedora was never "M million happy users, growing X% annually".

Actually, Fedora was.  Fedora initially followed on from Red Hat Linux
and was stable between releases, but this has gradually changed with
time.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedora mission (was Re: systemd and changes)

[Gerald Henriksen]

On Sun, 29 Aug 2010 09:43:16 +0200, you wrote:

>2010/8/29 Kevin Kofler :
>> Jesse Keating wrote:
>>> The cynic in me would expect that the people who want something different
>>> than the fire hose we have now are silently leaving, and those that are
>>> left are going to say they like the deluge of updates.
>>
>> You say that as if it were a negative thing. It's actually very positive, it
>> means we have found our niche and set some very specific expectations in our
>> user base! We should stick to that and not suddenly turn around half-turn.
>>
>
>Absolutely. For example, often criticized "having many updates" is
>IMHO a good thing, since it's really nice to see new git or new gnash
>without upgrading to pre-release version.

And how would you feel it the upgrade to git, or some other software,
caused you to lose days of time at work/home because something changed
that breaks your workflow?

If packagers are allowed to update packages when they want, what is
the difference between a released version and rawhide?

Users need the ability to assume that when they install a released
version of Fedora to use on their server/workstation/laptop that they
will be able to do their work, whether personal or at an office,
without the fear that applying an update will break their system.

If you reall need a newer version of git, gnash, or any other software
and your really can't wait the less than 6 months to the next release
then you have the option of risking breakage by installing it yourself
(either through compiling or trying a rawhide package).  But don't
assume that everyone else wishes to take those same risks.

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