Re: Easier %config management?

[Japheth Cleaver]

On 12/15/2015 10:54 AM, Christopher wrote:
On Tue, Dec 15, 2015 at 12:37 AM J. Randall Owens 
> wrote:


On 12/14/2015 02:47 PM, Christopher wrote:
> On Mon, Dec 14, 2015 at 11:22 AM Reindl Harald

> >>
wrote:
>
> i modified my "httpd.conf" based on Apache 2.2 years ago, as
Fedora
> swicthed to Apache 2.4 your approach would have compared a
customized
> Apache 2.2 version with a Fedora 2.4 version
>
>
> But, that's precisely what I want to do I want to know which
fields
> in the current configuration could possibly have introduced a
breakage I
> see... or which changes I need to make from a clean installation
to get
> a user back to the state they wanted.
>

But in order to do the former, you'd best compare the new default
to the
old default, to see what had changed in the default. (E.g. distro
2.2 to
distro 2.4) To do the latter, you'd compare the old default
(distro 2.2)
to your modified version (altered 2.2), to see what you'd changed
locally. And yet, you seem to be proposing comparing the new
default to
the old default (distro 2.4 to altered 2.2), which gets you
neither? (Or
both, really, but uselessly mashed together so you don't know which is
which.) Am I missing something?


I'm less interested in what the user intended to change in an older 
version than the full difference between the current default 
(presumably working) configs and the current files (which would 
include any user modifications AND any old defaults carried forward). 
The current system breakage could be the result of user edits, or a 
carry-forward of an older config. I don't care which is the case... I 
just want to see the differences to troubleshoot the problem... I just 
want to fix the system as it exists today... not question user edit 
decisions which occurred years ago.


Certainly, a full history, tracking all user edits, and all system 
updates, would be useful to some. It's just more than what I 
personally need, and seems a bit outside the scope of the existing 
installer tools (as previously stated with the suggestion to use 
etckeeper).




Full tracking of user edits and system edits, seems like a very 
development-focused perspective on config management. Sometimes, a 
sysadmin just wants to see what's different *now* without too much more 
detail.


For now, I think I'm going to write a script to parse the output of 
`rpm -V` and then `dnf download` all the packages corresponding to 
changed configs, then extract each rpm's %config files, to compare 
with those on the system. It's messy, but it'll work, and in the 
absence of rpm storing the full configs or being able to instruct 
rpm/dnf to reset configs back to the defaults (after backing up), 
there doesn't seem to be an existing solution that will give me the 
same result.


It seems like there's already a little bit of precedent for "alternate 
trees" representing the existing file system with the debuginfo rpms and 
/usr/lib/debug/ hierarchy. Although the easiest solution might be to 
have RPM deposit a duplicate copy of *all* config files (not just 
%config(noreplace)) adjacent to the config file actually read by the 
programs (e.g., /etc/httpd/conf.d/ssl.conf and 
/etc/httpd/conf.d/ssl.conf.rpmdist), that leaves lots of ugly, mostly 
unused, files everywhere.


Perhaps RPM (or yum/dnf, via plugin) could write a duplicate copy of all 
config files into a tree somewhere? (E.g., /usr/lib/config/ or 
/usr/share/config/?) RPM/yum/dnf could then do the equivalent of an `rpm 
-qlca` and compare each /etc/httpd/conf.d/ssl.conf to 
/usr/lib/config/etc/httpd/conf.d/ssl.conf with no real magic or complex 
tech needed. Merging left up to the sysadmin.


Having everything in one location might also give some future options 
for automated compression, refreshing scripts, and the like.


Regards,
-jc
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ntpstat

[Japheth Cleaver]

On 2/12/2016 3:36 AM, Peter Lemenkov wrote:

2016-02-12 12:10 GMT+01:00 Miroslav Lichvar :


I could write a new man page and put it in the ntp package as a
replacement. Or it could be added as a new package in Fedora, which
ntp could recommend or suggest. Would that make sense? Another option
is to simply drop ntpstat from ntp with no replacement.

Thoughts?

I'd simply remove it. Otherwise you have to act as upstream for this
outdated thing.


Whatever "outdated" means in this context, if it's functional (or can be 
made functional) and provides actual utility then why /not/ keep it?
I'd suggest it getting its own package, though, lest it get sucked into 
whatever systemd is doing with ntp.


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

Re: /sbin/nologin in /etc/shells

[Japheth Cleaver]

On 9/29/2016 5:55 PM, Kevin Kofler wrote:

Nobody should ever add this at all. And most definitely not Fedora.
The behavior the original poster pointed out:
| - su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as the
| default shell) succeeds with /bin/bash if auth is successful [2], even
| though man 1 su, man 8 nologin, and man 5 shells suggest that such a user
| is a restricted user and logging in with an alternate specified shell
| should be forbidden.
sounds very much like a critical privilege escalation security hole to me,
that should get a CVE and be fixed in all supported Fedora releases ASAP!



How is this a "critical...security hole"?  I seriously can't be the only 
person out there that intentionally sets accounts to /sbin/nologin if 
they don't need to log in (as another layer of security), but 
occasionally runs 'su -s /bin/my/shell/of/choice uid' when I need to do 
some work under it, can I?


In any event, this has been this way for 14 years. There are legitimate 
reasons for wanting a "valid" shell that, nevertheless, results in 
disallowing remote logins in a human-readable way. The traditional 
solution IIRC had been to set someone's shell to /bin/false, but I fail 
to see why -- 14 years later -- this is something I need to get a 
warning about, let alone something to be considered an actual problem. A 
sysadmin who runs "usermod -s /sbin/nologin" knows what they're doing.


If, as mentioned at 
https://bugzilla.redhat.com/show_bug.cgi?id=53963#c7, it didn't cause a 
problem in the first two years, "fixing" it 12 years after that seems 
unnecessary. We "fix" enough perfectly-working stuff in Fedora as it is...


+1 to fixing this by updating the shells man page as indicated in 
https://bugzilla.redhat.com/show_bug.cgi?id=1218302#c4


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

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Japheth Cleaver]

On 10/5/2016 2:40 PM, Chris Murphy wrote:

On Wed, Oct 5, 2016 at 3:14 PM, Przemek Klosowski
 wrote:


I think it is a mistake to require reboot for _every_
update, even though, as you say, even user apps sometimes _cannot_ be
updated online (*). I am comfortable with online updates, and I take more
drastic action---restart apps and/or reboot---only when I actually see
problems.

If you read all the posts I cited, it's pretty clear that the notion
updates are really being used if you haven't rebooted is entirely
illusory/wishful thinking. There's a good chance you wouldn't know
there were a problem.The only way to be sure is to reboot.

I don't know what the dnf equivalent is, but isn't that precisely what 
the 'needs-restarting' command provided?


And speaking more broadly, a competent RH-derived-distro administrator 
is already aware of this concern about libraries not taking effect. They 
also have the tools (lsof, etc.) at their disposal to make their own 
decisions on a live system about whether a service (or the host itself, 
for things like glibc) should be bounced when updating a library package.


It feels like any auto-restart behavior (outside of the %post scriptlets 
in the service packages themselves) should be advisory in nature.


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

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Japheth Cleaver]

On 10/5/2016 9:37 AM, Kevin Fenzi wrote:

On Wed, 5 Oct 2016 10:56:35 -0500
Bruno Wolff III  wrote:


On Tue, Oct 04, 2016 at 20:42:11 -0700,
   Adam Williamson  wrote:

The one thing I absolutely would advise against: don't do an update
over ssh! Unless you use screen or tmux, of course. But just sshing
in and running an update is a great way to potentially hit trouble.

This isn't as bad as you might think. While I mean to use screen, I
often forget and very rarely have problems as restarting sshd doesn't
shut down existing ssh sessions.

Right, thats the thing... 99.9% of the time you are just fine. :)

kevin


After a check-update preview, I can count the number of times "yum -y 
update &" has ever failed me over the years on one hand.


-jc

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

Re: /sbin/nologin in /etc/shells

[Japheth Cleaver]

On 10/3/2016 3:02 PM, Stephen John Smoogen wrote:

On 3 October 2016 at 16:53, Toby Goodwin  wrote:

I was just reviewing this thread to date, and came across somebody asking:


How is this a "critical...security hole"?

I'm wondering if perhaps some of the staunch defenders of the status quo
have missed the security hole?


Why do people have to think that people are being 'stauch defenders'
when they might just needed a clearer explanation? I know you
mentioned chsh in your original email but even after rereading it, I
am not able to make the leap from it to what you show below. What you
show below is clearly a security problem for multi-user systems
(though I expect that there would be arguments that you are not
supposed to use chsh /sbin/nologin to lock someone out but usermod
-L).

The owner of the setup package is Ondrej Vasik, email:
ova...@redhat.com. They seem fairly active and would probably be
receptive to fixing the problem with the explanation included.

My objection here is roughly the same. /sbin/nologin does not mean 
"locked out", it's a non-shell that can serve as a shell. While there 
may be some value in chsh disallowing a change *from* /sbin/nologin to 
something else by the own user, it's not intended to block any access at 
all by a user -- it's canonical purpose allowed FTP logins successfully, 
for example.


To prevent an 'su' specification of shell and to prevent any login, one 
can use /bin/false easily enough (which, again, was historical practice 
AFAIK). To prevent login via password (or an 'su' from one local user to 
another), usermod -L would seem to be more correct.


My concern here is that we're losing a useful tool: a built-in 
"non-shell" shell, functioning as a middle-ground between an invalid 
shell and an account lockout.



Regards,

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

Re: Supported way to require that a service be stopped prior to installing an .rpm package?

[Japheth Cleaver]

On 10/25/2016 6:13 PM, jha...@gmail.com wrote:

On 10/25/2016 4:47 PM, jhally(a)gmail.com wrote:

https://fedoraproject.org/wiki/Packaging:Scriptlets

It seems like this is something that could be done in %pretrans, as well. 
Alternatively,
depending on the paradigm you're working with, you could give service restart
responsibility to the rpm process itself. This already happens during most 
daemon updates
anyway, so if it's for your team's internal use, I'd consider saving state in
%pretrans, stopping the service (if running), and starting back up in 
%posttrans.

On 10/25/2016 5:10 PM, Subhendu Ghosh wrote:


I don't see why this needs to be the case.

Between %pre, %post, %verify, and the newer %*trans functions, along
with Requires(pre), etc, 'rpm' provides all the tools you need to
perform modifications of a service using easily-grokkable logic, already
running as root, and using easily-testable methods.

Edge cases like saving state have best-practice implementations already
available, and rpm scriptlets already perform this action for many
services. Meta-packages which perform service control aren't
particularly groundbreaking.

Regards,

-jc

Thanks for the response!  could you possibly point me to an example of what 
you're referencing?


Hmm. Well, it looks like things have moved around a bit on the wiki 
since I last looked them up, but the basic concepts were discussed at:
https://fedoraproject.org/wiki/Packaging:Scriptlets?rd=Packaging:ScriptletSnippets#Scriptlet_Ordering 



I do seem to recall actual code examples there, but I don't see it in 
the merged page history.


Essentially, you'd just be doing something like (untested):

%pretrans
# Check if running, if so, be sure to start back up afterwards
rm -f "/tmp/%{name}.upgrade.restart"

/sbin/service %{name} status >/dev/null && touch 
"/tmp/%{name}.upgrade.restart"

/sbin/service %{name} stop >/dev/null 2>&1


%posttrans
if [ -e "/tmp/%{name}.upgrade.restart" ] ; then
   rm -f "/tmp/%{name}.upgrade.restart"
   /sbin/service %{name} start >/dev/null|| :
else
   /sbin/service %{name} condrestart >/dev/null  || :
fi

exit 0


== * ==

This is untested, but adapted from some logic I'd had in some other, 
hairier, %pre/%post scriptlet that had to do some shuffling around of 
directories and symlinks. I've never actually had to use %*trans myself, 
so if %pre is working for you then I'd simply continue using that.


Note that any use of anything other than lua in %pretrans means that 
your RPM can't be installed at initial/anaconda time, since pretrans 
runs way at the beginning of whatever's happening.



Hope that helps,

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

Re: Supported way to require that a service be stopped prior to installing an .rpm package?

[Japheth Cleaver]

On 10/25/2016 4:47 PM, jha...@gmail.com wrote:

Hello,

My team is building and maintaining a fairly complex software stack that is 
being packaged via rpm.  As part of the requirements, the service provided by 
the .rpm file must be stopped prior to installation / update of the package.

Is there any supported / recommended way to do this?  Currently the team uses 
the %pre section to check if the service is running and fail if so, but this 
seems a bit ugly.


https://fedoraproject.org/wiki/Packaging:Scriptlets

It seems like this is something that could be done in %pretrans, as well. 
Alternatively, depending on the paradigm you're working with, you could give 
service restart responsibility to the rpm process itself. This already happens 
during most daemon updates anyway, so if it's for your team's internal use, I'd 
consider saving state in %pretrans, stopping the service (if running), and 
starting back up in %posttrans.

On 10/25/2016 5:10 PM, Subhendu Ghosh wrote:

Packaging methods should not be used for this requirement. You should 
be using some system automation tools like Ansible or Puppet or Chef 
to make that transaction complete smoothly.


Openshift uses Ansible for their cluster upgrades.



I don't see why this needs to be the case.

Between %pre, %post, %verify, and the newer %*trans functions, along 
with Requires(pre), etc, 'rpm' provides all the tools you need to 
perform modifications of a service using easily-grokkable logic, already 
running as root, and using easily-testable methods.


Edge cases like saving state have best-practice implementations already 
available, and rpm scriptlets already perform this action for many 
services. Meta-packages which perform service control aren't 
particularly groundbreaking.


Regards,

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

Re: RFC: Change the default hostname for Fedora 26+

[Japheth Cleaver]

On 11/9/2016 1:30 PM, Louis Lagendijk wrote:

On Wed, 2016-11-09 at 12:58 -0500, Przemek Klosowski wrote:

On 11/09/2016 08:02 AM, Simo Sorce wrote:

Although this is true, one thing we could do is set a default hostname
that is static ("fedora" or similar is fine), and teach the utilities
used to join an AD/IPA/etc.. domain to generate a new random hostname if
they detect the hostname is the generic "static" one.
The hostname is used in the install-time-generated disk volume names 
(/dev/mapper/fedora_myhostname-home), so changing it is confusing.

Would it make sense to leave the old names? or rename the volumes?
___
devel mailing list --devel@lists.fedoraproject.org 

To unsubscribe send an email todevel-le...@lists.fedoraproject.org 



Is using a unique volume group name not actually preferable.
If one needs to add a disk from one machine to another it avoids the 
problem of having 2 volume groups with the same name and therefore 
overlapping LV names.

I got bitten by that once.

/Louis


The problem is that those VG/LV names are distinct from the host they're 
a part of The only thing worse than a generic label for something is 
an incorrect or misleading one, as happens occasionally with clones, 
host renames or imaging a VM on top of that.


If we really don't have a better, persistent, local name for a system at 
install time, then I don't see why reverting to /dev/VolGroup00/LogVol00 
is horrible here. VG names should be human-readable and exist in a 
namespace; shouldn't uniqueness should be from VG/LV UUIDs when we need it?


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

Re: RFC: Change the default hostname for Fedora 26+

[Japheth Cleaver]

On 11/10/2016 8:45 AM, Richard W.M. Jones wrote:

On Thu, Nov 10, 2016 at 11:17:20AM +0100, Theodore Papadopoulo wrote:

On 11/09/2016 02:32 PM, Matthew Miller wrote:

On Tue, Nov 08, 2016 at 03:25:58PM -0800, Andrew Lutomirski wrote:

If the hostname is non-constant, can we also arrange that, by default,
this hostname is never sent over the network?  In particular, I think
that DHCP requests should *not* include this hostname.  We're already
starting to randomize MAC addresses -- there's no reason to give a
persistent per-installation identifier to every network.

There's two different cases that I'm not sure how to resolve elegantly.
On a home network or on a business network, having the name available
is highly desirable. On a public network, just the opposite.


Add a checkbox in nm so that users can state whether they are on a
trusted network or not ??

This is what Windows does.

I'm not sure it's a good idea for other reasons - almost no common
network should be "trusted" ...  Should you be sharing your machine
name on your home network that contains some insecure IoT crapware?

Rich.


It seems like that should be a policy decision made by an administrator 
or user (or at least the spin/distro builder), especially if the 
alternative means not having that flexibility at a low level of 
infrastructure.


We're still being gently nudged to be using NM on actual servers, right?

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

Re: RPM %changelog?

[Japheth Cleaver]

On 10/25/2016 11:35 AM, David Shea wrote:

Please, no, don't do that. RPM is a standard

lol.

  * The representation of file names in package headers changed in rpm-4.0.
  * Originally, file names were stored as an array of absolute paths.
  * In rpm-4.0, file names are stored as separate arrays of dirname's and
  * basename's, * with a dirname index to associate the correct dirname
  * with each basname.

That's just my personal favorite. The RPM standard is whatever RPM is doing 
right now.


While that may be true operationally (the switch in hash algorithms away 
from md5 that forced extra steps backporting to EL5 was annoying), the 
bigger issue is probably spec file design.


It's possible to create spec files (and thus SRPMs) mostly-compatible 
with a wide variety of different downstream uses. This is a good ideal 
to keep striving towards.


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

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Japheth Cleaver]

On 11/11/2016 9:08 AM, Lennart Poettering wrote:

I still believe we should stick to a generic hostname by default,
(though I'd rather use "localhost" than "localhost.localdomain" in
order to drop the redhatism that "localdomain" is), and make the IPA
client-side enrollment code automatically update to a more "unique"
hostname if the hostname is found to be unset or be "localhost".

I am also pretty sure that DHCP clients should suppress sending local
hostname information if the local hostname is unset or "localhost".


Given the text of RFC6761 
[https://tools.ietf.org/html/rfc6761#section-6.3], something like 
"fedora-XX.localhost" would also be an option, if we absolutely 
needed a domain component. ("localdomain." seems like a not-invisible 
number of root TLD lookups at http://stats.dns.icann.org/hedgehog/). But 
a simple "localhost" seems a sufficient default over this localdomain. 
redhatism.



On 11/11/2016 6:50 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Nov 11, 2016 at 12:13:48PM -, fred...@rambris.com wrote:

I like Fedora- for default hostname. If I don't care to set a hostname 
it would be an ok hostname for my machine. I would however like if the hostname 
setting would be more prominent in the installer. Possibly generating based on 
my name along the lines of:  fredriks-laptop.rambris.lan

Making the choice it more prominent is probably not necessary, if we
provide a nice default. Although it probably wouldn't hurt. The hostname
could be displayed in the summary or maybe the user creation dialogue
('Create user "user1@Fedora-123345"'?).


Anaconda having a distinct panel explicitly for setting the hostname, 
along with some knobs for setting the default, depending, for example, 
on if we've already gotten an IP during PXE, would be a good thing IMO.


Prompts and options would help with some kickstart situations, where one 
would like a chance to permanently specify it during install regardless 
of user accounts or install-time networking, and before we reboot for 
the first time.


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

Re: CVE-2016-8655, systemd, and Fedora

[Japheth Cleaver]

On 12/13/2016 7:00 AM, Matthew Miller wrote:

On Tue, Dec 13, 2016 at 12:14:44PM +0100, Lennart Poettering wrote:

Well, the security policies need to be adapted to the service in
question, hence a blanket switch to enable all of them for every
service is problematic. Let's say you block gettimeofday()
system-wide, but then run an NTP service: you just broke it...

I fear it's too late to turn on all sandboxing options by default for
regular services. If we would have had them back when we started we
of course would have made them opt-out rather than opt-in, but that's
too late now...

I'm not so sure it's too late, if we would publicize the change well
enough in advance and have some proven packagers dedicated to finding
any exceptions. It's a matter of how much priority we put on
preventative security measures.

For a less-effort version, we could update
https://fedoraproject.org/wiki/Packaging:Systemd and have an (internal)
marketing campaign asking people to update their packages (as
suggested, ideally upstream).



I'd much rather that effort be put into good SELinux policy 
evangelization, documentation, and perhaps additional admin-controllable 
booleans.


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

Re: Proposal: Rethink Fedora multilib support

[Japheth Cleaver]

On 1/5/2017 9:12 AM, Jonathan Wakely wrote:

On 05/01/17 09:56 -0700, Chris Murphy wrote:

Teamviewer comes in an i686 only package for Fedora. So is there going
to be this interim approach, and then yet another change when they're
expected to use FlatPak? That's a lot of changes... And are these two
approaches compatible with the other platforms they target, or are
they just likely to drop the one it stops working on?

I can hardly imagine Teamviewer is the only 32-bit only GUI program.


There are all sorts of proprietary programs like Skype that are only
provided as 32-bit packages (there's a "skypeforlinux" package which
is 64-bit but it's an "alpha" release).

Maybe it would work fine from inside a 32-bit container, I have no
idea, but we should be careful not to make it harder for normal users
to install and use software distributed outside Fedora. And not make
it harder for ISVs to provide RPMs that work on Fedora with minimal
effort.


I feel like if this happens it will hasten the day when those of us 
primarily working in EL-variant land have to consider a need for a new, 
EL-forward, RPM-based open source "community" OS.


Fedora's role of breaking all sorts of things because $shinyNewParadigm 
-- moving further and further from the semblance of stability available 
in just being an extrapolation of where RHEL and its derivatives end up 
-- does create certain operational borders. Eventually that friction 
becomes unbearable.


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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Japheth Cleaver]

On 7/17/2017 10:22 AM, Richard W.M. Jones wrote:

On Sun, Jul 16, 2017 at 11:13:28PM +0200, Kevin Kofler wrote:

Matthew Miller wrote:

I strongly dispute the idea that Fedora must be tied to a particular
packaging technology.

The particular packaging technology is what ensures that we have a coherent,
integrated system. Flatpaks by design cannot offer the kind of integration
that native packages can offer, neither in terms of using shared system
libraries (saving space), nor in terms of user experience (even with
"portals", there will always be kinds of interoperation that the sandbox
just cannot allow).

And if the users will get their packages in a generic format rather than a
native Fedora format, what advantage do they get from getting it from Fedora
to begin with? The point of delivering Fedora packages is to integrate them
into the distribution. Only native packages can provide that.

Exactly, upstreams might as well just deliver .zip files which unpack
into a single directory and provide a ./application.sh script to set
up the LD_LIBRARY_PATH and cgroups right.  That's basically what we're
talking about here when you strip it back to the essentials.

Rich.


The rediscovery of static binaries is basically what the entire industry 
discussion comes down to, which last I checked were still anethema 
within Fedora.


If people want a container and tarball-based OS, that's fine. There are 
Linux-kernel-based projects that excel at that. Why drag Fedora into 
that when it would be easier to create a new distribution focused 
specifically on that? Flatpaks fall into the same category.


Fedora is only in the position it's in because it inherited the goodwill 
of the original RedHat Linux distribution, and it (well, more 
specifically, Rawhide) remains the de facto upstream standard for the 
entire RPM-based community. If Fedora moves wholesale away from RPM, it 
might result in an amazing OS for someone... but there's hardly any 
reason for me to use it at all.


How many other fundamental changes need to be made to the core of the OS 
because GNOME/FreeDesktop.org users have edge cases they need covered? 
(If you think the previous changes have been well received, I'd invite 
you to take a look at the CentOS users list.)


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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Japheth Cleaver]

On 7/19/2017 8:05 AM, Owen Taylor wrote:

On Wed, 2017-07-19 at 12:56 +0200, Dominik 'Rathann' Mierzejewski
wrote:

On Tuesday, 18 July 2017 at 20:43, Owen Taylor wrote:
[...]

An example of where conditionals may be useful is when a library is
bundled into a Flatpak - the rebuild for the flatpak could skip
building the developer docs because they have complicated build
dependencies (graphviz or whatever.) We'll have to see how frequent
that is as we work through real examples.

The bundling thing is what I'm afraid of. If we don't make it a
requirement or at least a strong recommendation to unbundle libraries
from Flatpaks, then we'll end up with Android app store-like
ecosystem, where everyone bundles everything which is not in one of
the
runtimes and even runtimes duplicate libraries between each other,
because it's easy and not forbidden. And since there's no easy way
to track bundled stuff inside Flatpaks, we're much worse off than
where we are with RPM packages currently.

Bundling enables some of the key features of Flatpak - the ability to
try out new versions of an application even if they require library
versions newer than what you have on your system, the ability to have a
single binary package that can be installed on different Linux
distributions, the assurance that installing an application will never
prevent you from upgrading your operating system due to missing
dependencies, and so forth.

And yes, there are downsides from bundling. But we're trying to address
those downsides as much as possible. Some of that is in the Flatpak
system:

* Runtimes mean that common libraries (libc, X11, etc) and libraries
that often have security updates (image libraries, crypto libraries)
will not be bundled.
* The use of ostree for storage means that if the exact same file is
bundled in two separate Flatpaks, it will be only stored on disk and in
memory once.

And some of that is going to be in how we generate Flatpaks from Fedora
content:

* Bundled libraries will not be arbitrary source code builds, they will
be built from the exact same spec files in dist-git.
* We will track (via the PDC) what versions of what packages are
included in every Flatpak runtime and app we ship, and can
automatically rebuild and update the runtime and apps as needed.
* We will include a manifest of the component RPM versions in each
Flatpak runtime and app.

There are definitely some open questions, and we'll have to pay close
attention to how much duplication we are getting in practice, and look
at whether we need to adjust the composition of the Fedora runtime and
our build methods to reduce duplication, but it's definitely not going
to be a Wild West where every application you install on your system
has its own copy of libz that was downloaded somewhere off the
internet.
Isn't one of the selling points for this, however, the use of Flatpacks 
written/produced by generic third party app vendors to publish without 
specially constructed packages by Fedora participants? If that's the 
case, what's to say that any upstream Flatpack/container/image will have 
the same care of using runtime definitions or expectations as the ones 
curated by the Workstation WG (or Freedesktop group, or whomever)? Why 
couldn't a third-party app creator bundle libz on a regular basis 
"because it's easier"?


Of course, one could do that in an RPM too, but then it would be berated 
as a "badly constructed RPM". It seems like one of the point of 
Flatpacks is to reach out to app developers who can't be bothered to 
write a decent .spec file but whose apps we still want to have easily 
installable by Fedora users.


Multiple versions of apps installed in parallel aside, how does this not 
end us back up in the same place?


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

Re: GCL and SELinux: help requested

[Japheth Cleaver]

On 10/13/2017 2:41 PM, Richard W.M. Jones wrote:

On Fri, Oct 13, 2017 at 03:07:05PM -0600, Jerry James wrote:

But that's not the end of the fun.  GCL failed the mass rebuild this
summer.  It built successfully on every architecture but s390x.  On
s390x, the build failed due to a failed call to mprotect(), almost
certainly a sign that SELinux was in enforcing mode on the builder.
Was that a known issue with s390x builders?  And, if so, has it been
rectified since?  If so, I'll try building again.

AIUI the builders run with SELinux disabled.  Has this changed?

Rich.

Is there a particular reason for this? I'd think Permissive would be a 
better option, so that any issues can be noted and (potentially) 
resolved down the line.


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

Re: Fedora Lifecycles: imagine longer-term possibilities

[Japheth Cleaver]

On 11/15/2018 8:19 AM, John Florian wrote:
I totally agree, but we are talking about radical changes here and I 
think we should keep all options on the table.  If some particular 
path forward is overwhelmingly desirable, that is the time to decide 
if the push is worth it, not earlier IMHO.  If the proposal, whatever 
it be, is great and everyone  agrees its great, the seriousness will 
be automatic.  Fedora has a long history of catering to some niche 
ideals that parts of our community are dead against.  It's awesome 
that Fedora is so flexible, but if we're going to fiddle with the 
release model, lets find something we *all* get behind and be happier 
with for the next 15 years, however radical it might look like right now.


This becomes even more important when one takes into account Fedora's 
position as the defacto head of the overall Red Hat -based distro 
community, notwithstanding the Penrose Triangle presentiation... 
EL-rebuild users (CentOS and SL) being on the far side of a 
mostly-opaque hardening process are doubly removed from meaningful 
input, and if a Fedora LTS of any type (rings, alternating intervals, 
etc) is to address any of those needs, all RH-ecosystem users probably 
have input worth soliciting.


I would submit that "Fedora" deciding an LTS policy might beg the 
question. Maybe the answer is there being a stable/LTS upstream that 
"Fedora" can itself (as one among peers) derive and override from, 
Debian->Ubuntu style.


-jc

___
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

[Japheth Cleaver]

On 11/15/2018 3:54 PM, Jason Tibbitts wrote:


And to add in an additional argument that we didn't have a decade ago:
We're actually trying to evolve our packaging now.  EPEL with it's "old
RPM never changes" restriction is bad enough but fortunately limited in
scope.  Having years of Fedora releases that can never evolve but which
still hold back progress in Rawhide is just too much.

Really, this is what our downstream distributions RHEL and CentOS are
for.  That was the answer then and I don't see why it doesn't still
apply.


I'm not sure why punting like this is a good thing. RPM is a standard, 
moving along at what one might expect a core component to do, but to the 
extent that "evolving our packaging" means doing things at odds with or 
in an incompatible way other distros (whether downstream, "downstream", 
or not) this is not a feature, or very nice.


The use of *-rpm-macros packages to try to standardize deltas across 
distros helps, but calls out for a more organized and systemic, 
cross-distro and cross-release ecosystem approach. It's ugly enough now 
that IMHO any LTS discussion needs to take this into consideration even 
more.


"Let's remove Group tags from Rawhide specs because we don't like them, 
even though every other distro uses them and they're staying in RPM" is 
not a particularly positive recent example of Fedora stewardship over 
packaging, and I'm sure any EL6 sysadmin can provide more examples from 
the last decade.


-jc
___
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: Editions vs. Spins

[Japheth Cleaver]

On 1/13/2019 10:19 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Sat, Jan 12, 2019 at 07:51:34PM +0100, Kevin Kofler wrote:

Stephen John Smoogen wrote:

Side note, I was at a loss of what you were getting at. There were several
ways it could be interpreted and has been used by people in the past to
mean different things.

I think John's statement was pretty clear: The artificial distinction
between "Editions" and "Spins" needs to go away.


The problem is that there is an inherent conflict of resources here. When
we put everything on the download pages, everyone including the spin
owners say it was too confusing.

The issue of which spins/editions are promoted is orthogonal to the
issue of counting. After all, counting just reflects the actual
frequency of installations, not the reasons for it.

But counting may provide a fresh look at this issue. We'll have much
better data which spins/editions are used. If it turns out that KDE is
more popular than previous statistics showed, or that KDE has a higher
retention rate (the number of short-lived installations is low
suggesting that users "like it if they see it"), this would be a
strong argument to make the KDE spin more visible.

Zbyszek


Relying on use-data here seems counter-intuitive. Shouldn't the decision 
be made based on project first principles or community goals first, with 
visibility and marketing effort being put in subsequent to that to meet 
those goals?


-jc

___
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: Editions vs. Spins

[Japheth Cleaver]

On 1/14/2019 4:58 PM, John Harris wrote:

On Monday, January 14, 2019 6:48:47 PM EST Matthew Miller wrote:

Merging Core and Extras into one thing was absolutely the
right thing to do for the project, but not having a unique name for the
resulting OS was a mistake and leads to this. Ah well.

In your opinion, is the purpose of the Fedora Project something other than the
creation and maintenance of the distribution known as Fedora?


For better or worse, EPEL is under the aegis of the Fedora Project.

If "Fedora Workstation" became "Fedora", and the Fedora Project became 
something... else... , which reflected a broader purpose and set of 
stakeholders, I suspect a good amount of tension on cadence and policy 
might be resolved.


-jc
___
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 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Japheth Cleaver]

On 12/12/2018 2:20 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets

== Summary ==
Remove scriptlets which are not needed anymore (ldconfig,
gtk-update-icon-cache, etc.).

*snip*

== Upgrade/compatibility impact ==
Installed F30 RPMs on F28/EL6/EL7 might not work although it is not supported.

There's not much description in the link about what's actually going to 
happen here and what's being removed from .specs.


Is there going to to be any attempt at coordination of this with EPEL? 
Or, if these are already macros in the .specs, has there been thought 
given to simply changing some of these to no-op macros in Fedora instead 
of removing them entirely?


-jc
___
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: Proposal: Move to an annual platform release starting at F30

[Japheth Cleaver]

On 11/27/2018 10:39 AM, Owen Taylor wrote:

We can definitely talk about whether moving to a slower cadence for
certain parts of the base platform. But people don't judge Fedora on
how beautifully we maintain glibc and gcc - they mostly judge it by
installing it on a laptop and seeing how well it works. And it doesn't
really matter how reliably we can create minimal container images if
the workstation image doesn't compose or doesn't log in.


I'm not sure that that's fair. I mean, I judge Fedora on how much its 
features are likely to cause problems 9-36 months down the road in an EL 
release... or now, in the case of cross-distro integration and support. 
I could care less about GNOME, but care very much about gcc, glibc, the 
kernel, and packaging of libraries.


*Laptop users* certainly judge Fedora on how well it works on laptops, 
and Workstation environment users judge Fedora on the Workstation spin.


Any other statement would pre-suppose the exact answers this and related 
discussion would seem to be working towards.


-jc
___
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

[Japheth Cleaver]

On 11/16/2018 3:19 PM, Nicolas Mailhot wrote:

Le vendredi 16 novembre 2018 à 13:02 -0800, Japheth Cleaver a écrit :

I'm not sure why punting like this is a good thing. RPM is a
standard,
moving along at what one might expect a core component to do, but to
the
extent that "evolving our packaging" means doing things at odds with
or
in an incompatible way other distros (whether downstream,
"downstream",  or not) this is not a feature, or very nice.

I think you do not realise how much old rpm is holding us back, and how
much we limit ourselves in Fedora, and make ourselves more work, just to
cater to those old rpm limitations. A small number of people, that
include Jason Tibbitts, perform unappreciated heroic wonders all year
round to limit the damage old rpm deficiencies inflict on Fedora and
EPEL, and if you think the situation is imperfect, well it would be
terrible without them.

Really, if there is one distro component we should backport to el and
all release streams, that's rpm + all Fedora macro packages, not the
kernel.


Well, that's kind of my point. Packaging changes (not at the core level, 
like with the other thread) should not be Fedora-based, they should be 
in coordination *using macro packages* across the entire ecosystem. 
(Again, Group tag removal seems an obvious example.)


And coming from an EL6 perspective, what "old rpm deficiencies" are you 
referring to? Optional Recommends might be nifty new features, but 
somehow we're getting along without them still fine. (And, judging from 
reports, the semantics and kinks haven't been entirely worked out of 
those yet regardless.) If a core rpm forklift can be done safely onto an 
old release, then that's an option to be kept on the table (even in a 
stable release), but I'm hard pressed to think of any "deficiency" per 
se. (%trans processing and %build conditionals strike me as things it 
would've be important to backport.)



Classical rpm targets and works well for C/C++ projects that use
autotools, a static small list of dependencies, and release as an
archive. A growing part of the distribution does not fit this model any
more. git and the internet blew away any limit on the number and cadence
of dependencies for every language, including C/C++. Non C/C++ languages
do not fit in the C/C++ macro model. Those new parts needs the same
level of rpm support as previous projects, which means writing new
macros, that build on other new macros, and it all falls appart if you
can not rely on some of those other macros existing because of a time-
jump in el land.

Classical rpm macro argument processing is severely deficient, not even
on par with shell getopts-level of argument processing, let alone the
argparse-level many languages now sport. That creates a huge impedance
mismatch with modern commands that expect more elaborate argument
syntax. You can not drive them from rpm macros, you end up putting lists
of arguments in variables to pass them to commands behind the macro
argument parser. That should be fixed.


If you're discussing things like 3K-character-long java arguments, then 
I agree with you that that's painful. But I fail to see how the core 
needs of any build system (or install system) can be any more complex 
than arbitrary shell, and these sections already *are* arbitrary shell. 
I'd like to never have to tweak CFLAGS= in a %build, but it occasionally 
does happen. That doesn't mean it's a design flaw -- that's why code is 
allowed to be there. In a worst-case-scenario, one can always 
standardize on an external helper to adjust or modify things during 
execution (which has the added benefit of bench-testability and code 
re-use) and use a macro to call that.


I feel like this mirrors the debate between imperative initscripts and 
declarative unit files. Macros are great, and macros calling 
distro-defined helpers work, but a religious purge of shell does not 
really seem to be a win.




Most notably, all the dead-stupid %setup/%sources/Tag
processing, that you know any rpm novice will misunderstand and get
wrong, even before you attempt explanations. Those warts were merely
annoying when dealing with a few thousands of distro packages, they have
a real cost now the distro has grown.
How is this processing "dead-stupid"? I'm seriously asking here. It's 
not difficult, and it shouldn't be too much to ask that someone be able 
to figure out the syntax of a simple recipe file like this. I agree we 
were in an RPM-documentation deadzone for a while there, but I feel like 
there are plenty of examples and guides now for novice RPM users. 
Certainly seems easier to make an .rpm than a .deb.


-jc
___
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/

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/25/2019 2:10 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Mar 25, 2019 at 08:18:34PM +, Tomasz Kłoczko wrote:

Switching to other than bash sh interpreter allow reduce total gcc package
build time by ~5%.

OK. But that just shows that it is — possibly — worth to switch the gcc build
to a different shell, by working with gcc upstream. Nothing should be
extrapolated from this to other packages and in particular to their
spec files.


But why not? It's obvious that anything with a lot of forking and 
subshelling in it will be improved. Back when ash was part of the 
distribution I regularly got 30-35% concurrency improvements on 
resource-strained machines when my service had an unavoidable fork or 
three in it. (Looking at you, qmail.) I mean, nothing about 
https://wiki.ubuntu.com/DashAsBinSh has actually /changed/ in all these 
years, really.


It feels like there's been this vast movement to try to remove every 
last bit of shell from Fedora whenever possible, and I really don't 
understand the aversion. True, sometimes the the best answer to a 
dilemma about how to improve XYZ is "mu - let's remove XYZ", but a 
slavish devotion to that has some significant drawbacks. (It was 
mentioned above that Fedora found a much better way to deal with boot 
times, and I'd have to disagree. If you can take a one-time hit to 
remove bashisms and get a 25-40% improvement, that seems a far better 
deal than the years of misery and Linux civil wars the alternative 
precipitated.)


Transactions are nice, but they're not everywhere, and won't solve every 
issue a .spec might have. And that's certainly not necessarily the case 
for non-Fedora code. Given that shell won't ever really completely go 
away, there's nothing wrong with evaluating ways to increase 
compatibility, quality, and efficiency in our execution choices.


Part of that begins with ensuring mechanisms are in there for local SAs 
to hook useful decisions into. And making this more explicit allows both 
the RPM format and Fedora's relation to it to be better defined.


-jc


___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/26/2019 8:14 AM, Adam Williamson wrote:

On Tue, 2019-03-26 at 09:08 -0500, mcatanz...@gnome.org wrote:

On Thu, Mar 21, 2019 at 5:05 PM, Tomasz =?UTF-8?b?S8WCb2N6a28=?=
 wrote:

[tkloczko@domek SPECS.fedora]$ rpm -E %_buildshell
/bin/sh

How can this discussion still be ongoing? Why not just change it to
/bin/bash and move on?

Japheth Cleaver explained why in response to me a couple of days ago:
apparently changing it would also change the shell used for some
scriptlets...


Well, each of the build-time scriptlets (%prep vs %check, for example) 
have distinct shell macros that can be overriden -- they just default to 
whatever buildshell is if not.


The problem is that the *install-time* default shell can't be overriden 
at all.


-jc
___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/26/2019 8:47 AM, Japheth Cleaver wrote:

On 3/26/2019 8:14 AM, Adam Williamson wrote:

On Tue, 2019-03-26 at 09:08 -0500, mcatanz...@gnome.org wrote:

On Thu, Mar 21, 2019 at 5:05 PM, Tomasz =?UTF-8?b?S8WCb2N6a28=?=
 wrote:

[tkloczko@domek SPECS.fedora]$ rpm -E %_buildshell
/bin/sh

How can this discussion still be ongoing? Why not just change it to
/bin/bash and move on?

Japheth Cleaver explained why in response to me a couple of days ago:
apparently changing it would also change the shell used for some
scriptlets...


Well, each of the build-time scriptlets (%prep vs %check, for example) 
have distinct shell macros that can be overriden -- they just default 
to whatever buildshell is if not.


The problem is that the *install-time* default shell can't be 
overriden at all.


Sorry, this was a bit too cavalier. I'm speaking as a Fedora end-user, 
not in Fedora Infrastructure.


From an infrastructure/builder perspective, there's are some avenues 
for effecting this shell change, which may or may not be desired. For 
any consumers of built RPMs, there isn't. Distinct issues.


-jc
___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/26/2019 9:04 AM, Nicolas Mailhot wrote:

Le 2019-03-26 16:51, Japheth Cleaver a écrit :


As far as actually making changes in specs, let's try addressing that
separately and perhaps asynchronously. Most of the changes for things
likely to run in scriptlets are probably just straight mechanical
replacements. (We won't know until someone does a full scan, but I'd
bet if you're writing *really* complex stuff there, you've probably
already moved that to a packaged script that's executed as part of the
scriptlet instead.)


Or you used macros. That will inject shell snippets right and left.

Macros should be the most trivial of things to clean up, though. And 
would represent the most obvious low-hanging fruit.


In fact, it would be nice to do that regardless of where this goes.

-jc
___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/26/2019 5:24 AM, Nicolas Mailhot wrote:

Le 2019-03-26 12:29, Dridi Boukelmoune a écrit :

On Tue, Mar 26, 2019 at 8:43 AM Nicolas Mailhot
 wrote:


Le 2019-03-25 22:47, Japheth Cleaver a écrit :
> If you can take a one-time hit to
> remove bashisms and get a 25-40% improvement,

CPU time is cheap, packager time is not. Exchanging CPU time for "you
all should learn to write POSIX-only shell scripts" would be an awful
deal. The Java part of Fedora is slowly imploding right now because a
lot of people pushed their complexity on packagers, and the packagers
could not cope. The Fedora target should be to help packagers achieve
more with less work, not achieve less with more work.


I think the Java ecosystem is before all imploding because of build 
tools

promoting a quadratic complexity of dependencies in a "community" not
bothered to maintain compatibility in libraries and as a result the 
other

side of the community coin not updating dependencies they consume
unless they feel like they need it.


It's an ecosystem where tools do not orient devs towards easy to 
integrate choices. It's imploding because someone decided a long time 
ago @SUN not to bother optimising the integrator/packager time,and all 
the efforts to change the Java community values since have failed (and 
someone should look hard @RH why it has not leveraged its stake in 
JBoss/OpenJDK to improve the situation).


Another victim of those choices and Java ecosystem values was Oracle 
that found itself unable to release timely JDK security fixes when it 
had to in the first years after it bought SUN, the integrator chain it 
bought from SUN was that much broken.


Packager time is not cheap, it's not inexhaustible, it runs out. 
Wasting it on bashisms is not smart.


Packager time -- either within the Fedora project, or among the system 
users, system administrators, and system engineers of Linux 
distributions derived directly or indirectly from Fedora -- is not 
cheap, I agree.  But getting things Right is important, because it 
provides a foundation for those below you to make competent decisions 
based the calls made earlier.


Having had to deal with packaging java apps up myself for quite a while 
now, I'd agree that it's a hot mess and has been for some time. The 
tooling around the original ecosystem seemed to have no rhyme or reason 
with it, JPackage efforts never *fully* went anywhere, modern Java devs 
still (in my experience) have difficulty getting onboard with attempts 
by local OpsEng and admins to wrangle some site-level sense at things. 
It doesn't work for anyone. (I'm sure I'm not the only admin who rues 
this every time they have a 15-line process string in their 'ps' 
output.) Arguably the "Linux is too hard to have to grok" mentality 
among java app devs has driven some part of the tech industry's current 
trends.



However, I think the parallel with bashisms fails. Getting shell right 
is only as difficult as you make it and we're talking about syntax 
cleanup, not imposing a new paradigm on a lawless ecosystem. True, the 
other major Linux ecosystem that did this had always held a 
/bin/sh-stays-POSIX distinction in mind, and had made occasional audit 
efforts before, so it was easier. But they faced their own issues at the 
same time when they did their conversion... (Their init script 
environment (IMHO) was far less disciplined than RH's was at the time 
(and still is in rhel6), so there's that.) Nevertheless, we have a clear 
example here of how it's possible to get it done.


The fixes to RPM to make this even possible shouldn't be difficult. 
Bourne shell remains the shell language (unless otherwise specified for 
that scriptlet), but the "default Bourne shell" should be configurable 
-- everything else is. In theory, RPM is still the specified package 
format for LSB, so the more flexibility for weird environments the 
better. And Fedora overriding that to /bin/bash after that (if desired) 
seems trivial as well.



As far as actually making changes in specs, let's try addressing that 
separately and perhaps asynchronously. Most of the changes for things 
likely to run in scriptlets are probably just straight mechanical 
replacements. (We won't know until someone does a full scan, but I'd bet 
if you're writing *really* complex stuff there, you've probably already 
moved that to a packaged script that's executed as part of the scriptlet 
instead.) That advancement because a nearly insurmountable effort if we 
continue to, by policy, refuse at a core level to distinguish between sh 
and bash.


-jc
___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/25/2019 2:46 AM, Nicolas Mailhot wrote:

Le 2019-03-25 09:53, Jan Pokorný a écrit :


Good point, and that's something capable of making upstream
maintenance cumbersome at times (sed is a common pet peeve),
but that's an order of magnitude more demanding level when it
comes to portability, and with Fedora settled firmly just around
GNU approaches and extensions, there's hardly a pressing need for
the spec files to come anywhere close (but if so, the restrictions
should not be limited to shell interpreter alone as remarked,
since POSIX compliance is a wider topic).


More accurately, what is the point of wasting energy on making a Linux 
system POSIX-only today? POSIX was a useful tool to make proprietary 
unixes more or less compatible with one another. The situation has 
changed since. Linux has taken over most of the marketplace. That 
means the common compat layer you need to target to replace it with 
something else, is whatever major Linux distributions agree on, and 
that includes all the GNU tools with all their non-POSIX extensions.


The original point was on the execution shell, not external commands 
being run through it. Those can always vary according to the needs of 
the .spec writer, which is why Requires(pre/post) exist. (Using perl's 
broader compatibility to get around sed oddities springs to mind.) It's 
true that it's always good to strive for maximal compatibility whenever 
possible, but that's slightly orthogonal here.


It's clear that there are GNU/Linux systems that do simply use other 
Bourne shells by default, and users who would like to do so 
individually. Removing unnecessary bashisms would be very nice, but a 
sensible, coherent specification would at least be a good start.


-jc

___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/25/2019 5:12 AM, Florian Weimer wrote:

Fedora is so different from other GNU/Linux systems these days, so I'm
not sure if *any* recommendation to encourage portability (at the cost
of convenience to Fedora developers or users) makes sense anymore.
___


If this is true (and I'm not saying I disagree), then it feels like it's 
high time that "Fedora" (as indicated) be spun towards something 
distinctly and clearly /downstream/ from a process that *does* encourage 
portability, so that Red Hat ecosystem users with those desires in mind 
have a place to attempt to manifest them.


-jc
___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/25/2019 8:02 AM, Adam Williamson wrote:

On Mon, 2019-03-25 at 12:59 +0100, Dridi Boukelmoune wrote:

And since RPM appears to be configurable for the
default interpreter, have it use /usr/bin/bash by default.

TBH, it seems to me reasonable that we just do this.

If our position is that we actually expect Fedora package scriptlets to
be executed by bash and don't think it's a problem if they don't work
when executed by some other shell, why not this make this clear and
explicit in this way instead of having the default be sh, but then tell
people sh must be bash?


One caveat: I'm not sure current RPM allows this to be configured 
separately for builds versus installs.


There's a %_buildshell macro as of 2.4.101, but this only references 
%prep/%build/%install/%check/etc...
https://github.com/rpm-software-management/rpm/blob/ba85c95963f9b62f237c0442f6b5aca3e355fa83/macros.in#L801 



https://github.com/rpm-software-management/rpm/blob/ff4b9111aeba01dd025dd133ce617fb80f7398a0/lib/rpmscript.c#L408 

...seems like the default for unspecified %pre/%post/etc scriptlets 
might fall to the compiled-in /bin/sh. And the configuration of *that* 
might be the rejected proposal at 
http://web.archive.org/web/20150821020837/http://rpm.org/ticket/877


-jc

___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/26/2019 10:57 AM, Nicolas Mailhot wrote:

You want something faster than bash – write something faster than bash
with as expressive a syntax (and ideally the same syntax). Winning CPU
time by consuming packager time is not going to work.


This seems like it's begging the question. "The same syntax as bash" is 
just going to be bash. And if it's going to be bash, we should call that 
out as "bash," which is Step 0 for anything else.


Removing bashisms is /a/ change, but it's not a huge change for shell 
snippets here and there. (Unlike other parts of the distribution that 
would probably have a lot of gettext substitution to deal with.) Yes, 
there are syntax changes occurring, but most of it's going to be more 
along the lines of "Please tweak these C++-style comments so we can use 
a C compiler" than anything else.


-jc

___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/26/2019 8:14 AM, Adam Williamson wrote:

On Tue, 2019-03-26 at 09:08 -0500, mcatanz...@gnome.org wrote:

On Thu, Mar 21, 2019 at 5:05 PM, Tomasz =?UTF-8?b?S8WCb2N6a28=?=
 wrote:

[tkloczko@domek SPECS.fedora]$ rpm -E %_buildshell
/bin/sh

How can this discussion still be ongoing? Why not just change it to
/bin/bash and move on?

Japheth Cleaver explained why in response to me a couple of days ago:
apparently changing it would also change the shell used for some
scriptlets...


FYI: https://github.com/rpm-software-management/rpm/issues/646

___
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: Ditch RPM in favor of DPKG

[Japheth Cleaver]

On 2/20/2019 7:29 AM, Panu Matilainen wrote:

On 2/20/19 5:19 PM, Sérgio Basto wrote:

On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:

No, that was a bad joke from my end, what I need is proper apt in
Fedora to use sbuild.


If you also do the review-request for apt [1] it would be great
dh-python also welcomed :) [2]
The problem is apt is in use by apt-rpm and was not retired yet , we
need use another name , my propose is apt-debian .


Just FWIW, the fact that apt-rpm is still in Fedora is against the 
direct recommendation of the last upstream maintainer (as in, me).


It's been dead for ten years and is totally useless in todays Fedora 
with rich dependencies and all. Short of somebody stepping up to 
revive the upstream project, the only responsible action would be 
retiring it.



That may be the case for *Fedora*, but plenty of RPM-based distros don't 
use rich dependencies (optionally: yet), and .spec-writers may chose to 
avoid using them for maximal compatibility. That's not itself a reason 
to write it off.


-jc
___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/21/2019 3:23 PM, Richard W.M. Jones wrote:


So what?  On Fedora /bin/sh is bash, and bash is a fine shell.

All this nonsense of using dash for /bin/sh on Debian is IMO a
pointless bunch of make-work.

Fedora has certainly made a lot of make-work projects over the last 
decade, under arguably more questionable reasoning.


IMO the situation that we're in now ("Assume you're running in bash, but 
called as -/bin/sh") is a worst-of-both-worlds middle ground, somewhat 
akin to mandating webpages be written in IE Quirks Mode for all time. 
It's neither pedantically correct, nor flexible for users and 
downstreams. And the resolution from all of this last time remains 
lacking in the guarantees that an independent spec should have:


http://web.archive.org/web/20150821020837/http://rpm.org/ticket/877
https://pagure.io/packaging-committee/issue/184
https://bugzilla.redhat.com/show_bug.cgi?id=850706
via https://lists.fedoraproject.org/pipermail/devel/2014-October/202998.html

RPM should IMHO indicate scriptlets are to be written in Bourne shell, 
give a 'SHOULD'-level recommendation for POSIX-correctness, and provide 
a mechanism for distros to override that default. And If Fedora's 
packaging guidelines are going to continue to state that bashisms are 
completely OK, then it should use that override mechanism to set the 
shell to "/bin/bash" explicitly.



-jc

___
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: Can we maybe reduce the set of packages we install by default a bit?

[Japheth Cleaver]

On 4/9/2019 11:14 AM, Lennart Poettering wrote:

On Di, 09.04.19 12:54, Stephen John Smoogen (smo...@gmail.com) wrote:


This is more about socializing and teaching the systemd replacements...
because most of the systemd advocates and heavy users I have asked aren't
sure about how systemd replaces them and go back to cron/atd. I actually
think that the replacements seem much better thought out than cruft-ware
but.. but I also have little confidence I could get it to work consistently
while I can find 10k tutorials on cron.

Well, we addresses similar cases by placing README files or so in
those directories, so that people might notice if they are looking for
something there... i.e. /var/log/README is a similar case and
/etc/inittab too. I think we can do the same here too and make clear
that people need to install cronie first before these things work.

Alternatively. just drop the cron dropin dirs from the base image: if
i want to drop in a script in the dirs I should notice if I can't
because the dir doesn't actually exist.

Is this really worth the effort? cronie in F30 is a 103K package, and a 
decent chunk of that might be the ChangeLog. crontabs is all of 18K, 
which is 95% the GPL and the RPM header. It seems like a very small 
price to pay for something everyone is going to assume will be on any 
*nix-compatible system of note.


The last thing I'd want to have to deal with is solving for a missing 
/etc/cron.* because someone forgot to click a checkbox somewhere or 
didn't call it out in kickstart.


-jc
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Japheth Cleaver]

On 4/17/2019 10:36 AM, Lennart Poettering wrote:

On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote:


On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:

rngd runs as regular system service, hence what's the point of that
altogether? I mean, it runs so late during boot, at a point where the
entropy pool is full anyway,

I'd really like to see it start much earlier. Any way to make that
happen?

Well, no. I mean, the only way you can do that is by turning rngd into
its own init system, if you want it to run before the init
system.


This seems like a false dichotomy, no? Surely, things like this are a 
possibility:

https://lists.freedesktop.org/archives/systemd-devel/2010-September/000225.html

But beyond that, is there really no way to lift this earlier in the boot 
logic?


-jc

___
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: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

[Japheth Cleaver]

On 5/9/2019 7:46 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote:

On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote:

Hi,

let's drop the requirement and ordering on systemd (as implemented by
%systemd_requires) from packages which provide systemd units.

I now filed [1], which removes the recommendation to use %systemd_requires.
Quoting from that ticket:

Nowadays systemd.rpm does a preset-all call when it is installed.
This means that individual packages which provide systemd units and
call %systemd_post in their %post will work fine no matter if they
are installed *before* or *after* systemd.
 
Is this true for the version of systemd in RHEL 7 and compatible as well?

How will this affect EPEL packages?

systemd in RHEL generally follows the changes in Fedora, with a delay.
If this is changed in F31, then it wouldn't filter down to RHEL until
the next RHEL release. Similarly, such changes should not be propagated to
packages in EPEL7.

Zbyszek


RHEL8 has been out for all of two days. EPEL8 is still to come.

So long as EPEL (and Rawhide, tbh) are under the aegis of Fedora, it 
would be nice at least /some/ effort was made not to toss over 
incompatible changes, or a broad need for dist conditionals, across the 
package ecosystem with such cavilerity.


-jc
___
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: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

[Japheth Cleaver]

On 5/9/2019 4:14 PM, Nico Kadel-Garcia wrote:

On Thu, May 9, 2019 at 2:40 PM Zbigniew Jędrzejewski-Szmek
 wrote:


Also, if for some reason I don't grok one absolutely needs to use the
exact same spec file for Fedora 31+ and EPEL7 (which is based on F19),
than keeping the dependency as it is now is also an option. One extra
unneeded dependency is not the end of the world.

Zbyszek

It's useful to have one spec file. Maintaining 2 or 3 spec files means
maintaining and keeping synchronized 2, or 3, synchronized git
branches or shoving in logic to detect different build configurations.
This kind of logic is already in practice for RHEL, EPEL, and Fedora
for many packages, even though it is often applied inconsistently.


Not to mention that this is more or less the entire point of having an 
SRPM available. Packaging means that if I need a differing version of 
something on my system, I can often grab the latest .src.rpm and 
recompile locally, and -- subject to ABI compatibility restrictions 
(which will be being taken into account anyway) -- this often Just Works.


No RH SysEng or systems administrator is going to head to a Fedora git 
branch and check out individual components as a starting point. Thus, 
every tiny structural change like this made without regard to backwards 
compatibility (by, say, making a macro a no-op at the distro level 
instead) makes it harder and harder to actually leverage what's in the 
RPM ecosystem.


-jc
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Japheth Cleaver]

On 4/10/2019 4:10 AM, Brian (bex) Exelbierd wrote:

On Tue, Apr 9, 2019 at 8:40 PM Japheth Cleaver  wrote:

Is this really worth the effort? cronie in F30 is a 103K package, and a
decent chunk of that might be the ChangeLog. crontabs is all of 18K,
which is 95% the GPL and the RPM header. It seems like a very small
price to pay for something everyone is going to assume will be on any
*nix-compatible system of note.

I read, possibly misread, the original comment as being about the
number of "unneeded" things in the install, not necessarily the weight
of the specific packages.  What I think we are hearing from
containers, OSTree, etc. is that there is a group of people that wants
their systems more minimal with less unnecessary stuff.


*snip*


This seems to go back to who is the primary target audience for our
Workstation edition and what do they want/expect.  Then we can
document the changes and socialize them over a few releases so that
other users can get to where they want to be.  Basically "extra" isn't
what no one wants, its what our defined target doesn't want/expect.


Although this was originally posted about Workstation, I can virtually 
guarantee that a solution accepted for implementation would not be 
"Remove cron in %post," thus this really comes about as removing it as a 
default install pretty much everywhere. Of course, things like 
OSTree/atomic, containers, and micro-environments where every byte 
counts are likely to be bypassing typical installation mechanisms 
regardless to fine-tune what's delivered -- eg, removing documentation, 
etc in docker kickstart %post, or re-implementing parts of RPM to begin 
with.


Reducing the Minimal size is, in general, good, but it's possible to go 
too far, and I think that's the case with low-level, *nix wide tools 
like this. I'm reminded of the time someone thought tar needed to go 
too: https://bugzilla.redhat.com/show_bug.cgi?id=1409920


One might make the case for a removal from @core -- *maybe* -- but 
definitely not @base.




Lastly, taking a position on some of this, for example, removing cron,
is a form of opinionation that calls back to our roots of innovating
in the OS space.  We would be saying, we recognize this is the way we
did things X years ago, but there are new ways and processes and we
see value in those.  If we can't remove these things, then we are
being a good distribution by pointing out where solutions that claim
to fix something have fallen short so that those upstreams can make
decisions about what to do.


But what, exactly, has cron fallen short in? I'm reminded of that old 
testimonial tag line for the similarly named, but unrelated, utility 
cronolog: "cronolog kicks ass in every conceivable way in which a 
utility like cronolog can kick ass." ( 
http://web.archive.org/web/20090627031834/http://cronolog.org/ ) There 
are other launching mechanisms, sure... I've worked on one of them, but 
that doesn't mean there's anything wrong with cron, or /etc/cron.*/ 
directories.


More directly, I'm old enough to remember when we were assured that 
systemd's timers were not "to be in competition here" with cron, and and 
it was promised to "make sure that cron is advertised as a good solution 
for people who just want to queue a simple cronjob." With all the 
discussion of ease-of-use and discoverability, removing the "good 
solution" mechanism for users in favor of something requiring a package 
install doesn't seem to be a great example of that. 
https://lists.fedoraproject.org/pipermail/devel/2014-March/196293.html




The last thing I'd want to have to deal with is solving for a missing
/etc/cron.* because someone forgot to click a checkbox somewhere or
didn't call it out in kickstart.

Yes, but I also don't want to deal with a security fix in cron when I
didn't want it to begin with.  Adding software the user doesn't want
to have it as assumed for other users is always a trade-off.


True, but - as written elsewhere - that can be taken to a logical 
extreme, both via removal of simple, auditable utilities and shell 
scripts, and eventual giant replacements.


-jc
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Japheth Cleaver]

On 4/11/2019 8:32 AM, Przemek Klosowski wrote:

On 4/11/19 10:16 AM, Lennart Poettering wrote:

However, that's intended for system services only (i.e. for services
running as users UID < 1000). For regular users (i.e. human ones,
those with UID >= 1000), the idea is to install timer units in the
per-user instance of the systemd service manager instead. That service
manager runs inside a PAM session of the user, and the lifetime is
normally bound to the time the user is logged in, meaning that users
who are not logged in cannot run stuff. (however, specific users can
be marked as "lingering" though a privileged operation and if so
their specific service manager is started at boot and stays around
until shutdown, so that their timers can run outside of the immediate
login time of the user).


I think you're saying that systemd is designed on an assumption that 
such jobs are part of system operation, and  will have to run as 
system/privileged jobs or at least be designated as 'lingering', which 
you say requires system privilege. I would argue that on my own system 
(which is a majority of systems now) it should be easy to designate 
low-privilege jobs as lingering: I should get to decide if it's useful 
for them to run even if  I don't have a current login session.



While we're discussing session-tying for cron-esque background 
automation, it would be nice to have a resolution for 
https://bugzilla.redhat.com/show_bug.cgi?id=911766

via https://bugzilla.redhat.com/show_bug.cgi?id=995792#c16

It's unfortunate that it still fills up basic syslog with it: 
https://access.redhat.com/solutions/1564823


-jc


___
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: RFC: Drop lz4-static

[Japheth Cleaver]

On 8/14/2019 2:08 PM, Jason L Tibbitts III wrote:

"DS" == David Sommerseth  writes:

DS> As I can see it, there is little benefit of removing lz4-static.

Isn't that entirely the decision of those maintaining the package?  It's
still completely reasonable if they want to remove it for no other
reason than it eliminates ten lines from the specfile.  The question was
whether there is any pressing reason to refrain from removing it.

  - J<


Compression libraries are an area where it's common to have special 
cases that need to bootstrap or otherwise provide a service outside of a 
sane/guaranteed dynamic library environment. As others have mentioned, 
this could mean early boot for RH-style systems, but it could be for any 
other reason for a specific site. zlib-static, bzip2-static, and 
xz-static have existed for forever, and lz4 should continue to follow 
suit. (And https://bugzilla.redhat.com/show_bug.cgi?id=1212209 would be 
nice, since the subject is up.)


If it's removed for the .spec (not just not included in a distro, but 
removed), then those who'd like to be able to use the package have to 
maintain a new local fork. That's not ideal.


-jc
___
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 Workstation and disabled by default firewall

[Japheth Cleaver]

On 8/27/2019 4:01 PM, Adam Williamson wrote:

On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote:

mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300:

On Tue, Aug 27, 2019 at 4:22 AM, John Harris 
wrote:

No, that is not how this works, at all. First, let's go ahead and
address the
idea that "if the firewall blocks it, the app breaks, so it's the
firewall's
fault": It's not. If the firewall has not been opened, that just
means it
can't be accessed by remote systems until you EXPLICITLY open that
port, with
the correct protocol, on your firewall. That's FINE. That's how
it's designed
to work. There's nothing wrong with that.

This means that the system administrator (or owner, if this is
some
individual's personal system) must allow the port to be accessed
remotely,
before the app can be reached remotely, increasing the security of
the system.

You've already lost me here. Sorry, but we do not and will not
install a firewall GUI that exposes complex technical details like
port numbers. Expecting users to edit firewall rules to use their
apps is ridiculous and I'm not really interested in debating it.

Yeah, when you ask users questions they're not qualified to answer,
you're just creating bad design.
I always imagine my mom (who BTW has been a Fedora user for years) how
she'd deal with that and I can't really imagine her opening/closing
firewall ports. She'd be puzzled even by "Do you trust this network?"
and would probably just click "Yes" to make it go away. No additional
security, just annoying UX.

However, Fedora Workstation is an edition. Which means it has a
*policy-defined* target audience. That target audience is defined here:
https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience

Case 1: "Engineering/CS student"
Case 2: "Independent Developer"
Case 3: "Small Company Developer"
Case 4: "Developer in a Large Organization"

Are those people we believe do not understand the concepts associated
with firewalls?


The term "Workstation" itself has a long pedigree and is laden with a 
variety of connotations. The failure here may be that that term has been 
conflated with "Desktop". Your mother surfing Facebook may benefit from 
a "Linux Desktop" (maybe.), but she's probably not the target for a 
"Linux Workstation" unless https://xkcd.com/327/ is likely to happen.


"Fedora as a Distro" could do a better job of articulating this 
distinction. Perhaps a user vs. poweruser split is viable at 
install/config time, or perhaps Desktop and Workstation would warrant 
separate Editions.


"Fedora as a Project", OTOH, seems to be reaching a point where so many 
downstream users have varying needs (and I'm including Editions, Atomic, 
Container folks, EPEL as a side project, and RHEL/CentOS/SL here) that a 
fundamental project re-architecture is getting to be warranted.


-jc
___
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 Workstation and disabled by default firewall

[Japheth Cleaver]

On 8/29/2019 8:10 AM, Adam Williamson wrote:

On Wed, 2019-08-28 at 23:13 -0400, Christopher wrote:

On Wed, Aug 28, 2019 at 8:56 PM John Harris  wrote:

It might be okay to be a GNOME-specific thing, as that's the only spin of
Fedora which is affected by this decision.


The default firewall config affects every user of that edition, even
if they never use GNOME (or even use graphical boot). So, I don't know
if this would be adequate.

Why would you install Workstation if you didn't intend to use GNOME?


That would seem to be a reasonable question, but if it's possible to do 
so then it is bound to happen... It may be a symptom of unclear definition.


If Workstation is going to require a graphical environment for 
reasonable usage/administration/whatever, then it should be made 
mandatory somehow. It would also help clarify that the Workstation, 
Server, and  Products must be treated distinctly... and that you 
shouldn't just point your kickstart file at whatever ISO you happen to 
have laying around.


-jc
___
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: Upcoming change for adopting orphaned packages and anitya integration

[Japheth Cleaver]

On 9/17/2019 9:39 AM, Pierre-Yves Chibon wrote:

On Tue, Sep 17, 2019 at 10:21:31AM +0200, Till Hofmann wrote:


On 9/13/19 12:32 PM, Pierre-Yves Chibon wrote:

## Anitya integration

Currently if you want to tweak the setting for the anitya integration, you need
to open a pull-request on the fedora-scm-requests project at
https://pagure.io/releng/fedora-scm-requests/
That git repo is pretty big and once your pull-request is finally open, you
still have to wait for someone to merge it.

This is also going to change, new versions of pagure and pagure-dist-git offer a
drop-down menu on the left hand side menu to see and adjust the monitoring
status of the project.

This is also live in staging and you can see an example of a project who has set
its monitoring status to "monitoring":
https://src.stg.fedoraproject.org/rpms/0ad

(The status in staging have been imported from the fedora-scm-requests repo)


This is great to here! Would it be possible to have a page that shows
the monitoring status of all my packages? Does that even exist already?
I find myself repeatedly going through all my packages one-by-one to
check the monitoring status, and I still miss a package once in a while.
(This will already get easier with the new buttons, though).

No page but writing a script for this should be straight forward.
I am mostly AFK this week but I can cook up something for this next week :)


Even something like being able to mark user "Favorites" within the 
Anitya interface would be quite helpful, and open it up for others who 
might want to stay abreast outside of BZ package-owner integrations.


-jc
___
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: RPM Fusion Bugzilla Bug 5307

[Japheth Cleaver]

On 9/23/2019 10:55 AM, Neal Gompa wrote:

On Mon, Sep 23, 2019 at 1:49 PM Ty Young  wrote:


On 9/23/19 9:56 AM, Neal Gompa wrote:

The problem with that is that if we did it that way, nobody would
adapt to the change. Much in the same manner that we're moving to
cgroups v2 in Fedora 31, if we didn't do it, we can't suss out
breakages and fix them (if possible). And if third parties that don't
keep up with these changes (especially one that happened in 2013 for
Fedora GNOME!), there's not much that can be done.


Fedora is not Linux. You are not the sole arbiters of what gets changed
in the Linux ecosystem. You all need to get that through your damn
heads. No other distro/DE besides Gnome supports this and it doesn't
look like that's ever going to change.


We are not, sure. But the Fedora distribution is allowed to have the
opinion to do new things and see how it goes. Each of the spins are
allowed to work towards implementing this whenever they want. I
suspect at this point we're mostly waiting to move to Wayland on the
spins rather than doing work on Xorg stuff.



This is true, but somewhat sidesteps the very real point that "Fedora 
Linux" has a larger-than-normal impact on the Linux ecosystem as a 
whole, as well as that it's essentially the branching upstream of RHEL, 
and thus all EL-derivatives.


IMHO it's entirely justified to criticize Fedora for questionable 
decisions or decision-making when those decisions impact non- "Fedora 
Linux" users. Disallowing that smacks of wanting to have one's cake and 
eat it too when it comes to influence. (See also: Fedora v. FreeDesktop 
decision-making)


-jc
___
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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

[Japheth Cleaver]

On 9/30/2020 1:26 PM, Neal Gompa wrote:

On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher  wrote:

On 9/30/20 2:19 PM, Michael Catanzaro wrote:

On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher  wrote:

And what about places where NetworkManager isn't used?  (Just because
it's the default, doesn't mean that it's used everywhere.)

NetworkManager is used everywhere by default. If you want to disable it,
you have to do manual work to do that. If you do manual work to disable
NetworkManager, you can also do manual work to disable systemd-resolved.

Indeed, but I was responding to this:

On 9/30/20 1:35 PM, Neal Gompa wrote:
  > Please, no more package splitting. And NetworkManager is used across
  > all variants of Fedora, so resolved should be installed in all places
  > where NetworkManager is used.

Which (to my reading) says that because NetworkManager is the *default*
everywhere (even though it can be uninstalled), systemd-resolved should
be *installed* everywhere (and should not be uninstallable).  I don't
follow that logic.

There are not a ton of advantages for splitting it, since it's only a
couple of binaries averaging 2MB with a few unit files. Given that we
require it for default NetworkManager configurations now, there's not
a lot of value in making that complicated. Splitting has a cost too,
in the form of extra metadata, upgrade paths, etc.

Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
variants, as shipped today, *MUST* use NetworkManager.
NetworkManager's configuration will use resolved as a local resolver.
Anything baked into an OSTree cannot be removed anyway.

And like it or not, all our legacy network configuration mechanisms
are deprecated and *will be removed eventually*.

Literally the only reason networkd was split out was because Fedora
CoreOS was chainsawing it out at image build time and making it
impossible for people to use it. To be frank, I do not want more
permutations this low in the stack. It makes life incredibly difficult
for figuring out working network setups.

Splitting it out this low in the stack makes it easier to support (and 
create) cases where it's not used. What Fedora decides here still has 
knock-on effects downstream, including what EL users deal with. If 
there's a logical separation (and there is, and always has been), then 
discrete packages allow competent SA's to reduce on-system complexity. 
That really should be all the justification necessary IMHO.


-jc
___
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: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Japheth Cleaver]

On 12/4/2020 12:35 PM, Stephen John Smoogen wrote:


Anecdata which is as 'useful' as any other.

Most of the people I have dealt with in the last 4 years with Server 
have been using it mainly as a replacement for the Everything DVD and 
because it was the most 'un-opinionated' release of Fedora. It wasn't 
actually being used in any more of a server release as much as a 'get 
out of my way' while still using Fedora.


For the people who were using it as servers, it was split between 
getting ready for the next RHEL/CentOS they would be deploying, they 
needed packages which were not in EPEL, or things like 
python/nodejs/etc was new enough for what they needed to run but 
wasn't in EL8.


It would be interesting to consider how Fedora Server use cases change 
over time during an EL release cycle.


For many server use cases where the box is NOT ephemeral, when CentOS 
and Fedora are similar, it's likely that CentOS is going to be a 
better-engineered and tested option. But as time goes on and the next EL 
release isn't either isn't announced or isn't stable enough to rely on, 
Fedora Server probably sees more use as a quasi-stable release base.. 
This fills a real need when your users are absolutely clamoring for 
things that aren't likely to be backported into the stable EL release 
and you don't want to have to send them into Ubuntu/Debian land (or have 
them grab an un-administered container off the shelf).


In fact, Fedora Server as a "not EL, but better than nothing as a 
temporarily stable platform" during these later periods could be a 
useful niche to fill. Bonus points for some of those extended support 
duration/stable discussions from a few years ago.


Ultimately, however, I feel like the use case of Fedora Server is 
inexorably tied to the RHEL/CentOS (or CentOS Stream) discussions. And a 
Fedora WG that tries to do long-term planning and positioning needs to 
be part of those overall discussions for the greater good of the RedHat 
ecosystem. Short term marketing is fine, but the different sides of 
RedHat need to be on the same page about this all.


-jc

___
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 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Japheth Cleaver]

On 12/17/2020 3:59 PM, Matthew Miller wrote:

On Fri, Dec 18, 2020 at 12:51:49AM +0100, clime wrote:

This change proposal does affect users.  The User Experience section
needs to answer the following:

Well, the users here are still packagers here no? I thought the "User"
in the title means "end user" who shouldn't be affected by it. Maybe
Ben can clarify this.

It _is_ meant to refer to end users, but we have a lot of highly technical
end users and sysadmins who might want to download and build source RPMs. So
the answers to these questions seem like reasonable things to add.



   They can use mock if the preprocessing will be enabled for the
   respective chroots where it is enabled in Koji/Fedora.
   They can't directly use rpmbuild for those packages that contain the
   macros. But they can use rpkg/fedpkg to do the work.
   Or preprocess spec first and then use rpmbuild. I am aware this is a
   negative point of this change.
   While having an option to use rpmbuild directly to build srpm/rpm from
   a dist-git repo is nice, I would say that fedpkg or mock are the main
   interfaces to do this.
   I know this answer won't satisfy everyone.


Not to mention the many folks who use Fedora .src.rpms as a starting 
point for EL-derivatives, or other RPM-based distros. Every time a 
Rawhide (or Fedora) SRPM fails to compile because of a 
non-backwards-compatible change, another frustrated sysadmin sheds a 
single tear.


Deprecating rpmbuild is a major change.

-jc

___
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

[EPEL-devel] EPEL, Playground, CentOS Stream, etc

[Japheth Cleaver]

In light of the announcement, but also specifically:

https://centos.org/distro-faq/#q8-i-need-to-buildtest-my-packages-for-epel-locally-which-i-used-centos-for-centos-stream-will-have-different-abiapi-at-times-so-my-builds-wont-work-with-that 


https://centos.org/distro-faq/#q9-epel-8-needs-access-to-packages-which-are-not-shipped-by-rhel-but-were-made-available-by-centos-how-is-this-going-to-be-solved

...it seems appropriate to open up a discussion here.

With point releases, at least there was the possibility of flag days 
around EPEL ABI changes, however with a rolling release format there 
seems to need to be an active synchronization around such changes, as 
"expected" breakages aren't really occurring around a public release cycle.



Beyond this, I feel like the situation between the RHEL, CentOS, and 
Fedora groups here is becoming more and more untenable. If CentOS Linux 
is going away (after EL7), then there really needs to be more clarity 
about what mainline EPEL is targeting. And if there's a version of EPEL 
that's going to target CentOS Stream after all (and it's not EPEL 
Playground), then it needs to be marked as such.


(And, IMHO, it raises even more questions about that being under 
Fedora's aegis rather than that of the "community" it's serving.)


-jc
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org