Re: Should 'dnf install gtk3-devel.i686' work?

[Reindl Harald]

Am 21.01.2016 um 14:34 schrieb Yanko Kaneti:

On Thu, 2016-01-21 at 09:38 +, Richard W.M. Jones wrote:

On Thu, Jan 21, 2016 at 11:10:22AM +0200, Yanko Kaneti wrote:

On Wed, 2016-01-20 at 15:50 +, Richard W.M. Jones wrote:

If you're on freshly installed Fedora 23 (x86-64), then

   dnf install gtk3-devel.x86_64
..

Is this a bug or is it not expected this would work or I am doing
it
wrong?


IMO trying to get this (i686 development environment on x86_64
native
install) to work reliably and chasing down all the corner cases is
futile, leads to confusion instead of improving the developer
experience in any significant way compared to using mock and should
be
declared unsupported.


The logical consequence of this is we would get rid of multilib
entirely.


Not really. Runtime multilib is quite valuable feature, as any user of
closed source blobs (Steam!!) could attest.


the same for wine and windows games

(not that i personally have any i686 package installed)



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Debugging practices and hardened packages

[Reindl Harald]

Am 19.01.2016 um 12:36 schrieb Tom Hughes:

On 19/01/16 11:32, Jakub Filak wrote:


I cannot tell how it works in coredumpctl but ABRT C/C++ plugin can
be configured to ignore any path (this feature will be available in ABRT
2.8 [1]).

Right now, you can configure ABRT to drop core files of certain programs
by adding program path to the BlackListedPaths option in
/etc/abrt/abrt-action-save-package-data.conf [2]


It doesn't really help with the "big core dump" problem though because
the kernel still sends the whole thing to the pipe and abrtd still sits
there churning CPU for ages reading it out of the pipe, it just doesn't
do anything with it


then that's ABRT problem because systemd-coredump has no iusses with 
simply log that a coredump of eclipse with 3 GB process size was ignored




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Reindl Harald]

Am 18.01.2016 um 13:39 schrieb Heiko Adams:

Am Montag, den 18.01.2016, 12:27 + schrieb Jonathan Wakely:

On 18/01/16 07:05 -0500, Honza Šilhan wrote:

yes, autoremoval issue could be either caused by bad packaging [1]
or when you are
installing packages via yum or packagekit [2]. We are working on
better integration
between DNF and PK so this could be fixed soon. At the meantime use
this workaround [3].


It's a *terrible* workaround though. "Make a note of everything that
gets installed using PK and then as root run dnf to mark them as
userinstalled". A better workaround is "Don't use PK to install
things, use DNF". Why bother using PK at all if you then have to go
and run DNF commands for the same packages? You might as well just
use
DNF.

Because sometimes PK says there are updates available while "dnf update
--refresh" says no updates are available?
Happend to me several times in the past.


that's the drawback of dnf-makecache.timer because it may cache 
something shortly before updates are pushed and without that caching it 
would be refresehd when it's attempted to be used and so contain recent data


mask that timer and you are done
that never should have been introduced as default

the logflood "Cannot add dependency job for unit dnf-makecache.timer, 
ignoring: Unit dnf-makecache.timer is masked" should go away soon 
(referenced in a different thread and a systemd bugreport of some otehr 
person)




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Reindl Harald]

Am 18.01.2016 um 13:16 schrieb Jonathan Wakely:

And the fact that /var/log/dnf.rpm.log doesn't show updates done by PK
is just annoying. Isn't there a single log file I can look at to see
what was updated, and when?


currently no because dnf, PK and yum-deprecated using different logging 
instead just point to a generic "/var/log/packages.log" or how ever called


that's also annoying when you need to use yum-deprecated to get your 
tasks done, at least that and 
https://bugzilla.redhat.com/show_bug.cgi?id=1273925 could have been 
avoided (logwatch would have then contained the informations scratched 
with the premature logrotate)






signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Standard, consistent subject lines for automated emails

[Reindl Harald]

Am 18.01.2016 um 16:27 schrieb Matthew Miller:

On Sat, Jan 16, 2016 at 01:34:12PM +, Richard W.M. Jones wrote:

A related topic is headers, which could be used for filtering.
Various systems add headers -- see examples below -- but again there's
not much consistency and the headers aren't particularly useful for
filtering.


A standard header indicating just that the message is automatically
generated would also be helpful, for a) putting them in a separate
folder and b) filtering them out of analytics


the redhat-bugzilla does that after a bugreport from me long ago and the 
main purpose of them is to avoid autorepsonders (all sane autorepsonders 
supress replies if that headers are present, not only but also for 
loop-protection)


Precedence: bulk
Auto-Submitted: auto-generated



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Reindl Harald]

Am 18.01.2016 um 02:32 schrieb Zbigniew Jędrzejewski-Szmek:

On Mon, Jan 18, 2016 at 12:55:54AM +0100, Heiko Adams wrote:

But it seems to be broken since Feb 2015, which is IMHO unacceptable
since a default package manager and all of its features have to work
absolutely reliable.


When was the last time you saw a program bigger then /bin/true that was
"absolutely reliable"? Your implicit premise that yum was bug free
is completely bogus, just look for yum bugs in bugzilla [1].

It seems that with dnf we are currently in the phase of fine-tuning
user interaction. The resolver works nicely


the resolver works NOT nicely - hence that whole thread and bugreport



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Reindl Harald]

Am 18.01.2016 um 04:16 schrieb Kevin Fenzi:

On Mon, 18 Jan 2016 00:53:00 +0100
Reindl Harald <h.rei...@thelounge.net> wrote:

...snip...



why?

because you don't type "dnf install kernel" instead "dnf upgrade" and
"kernel-headers" *is never installed* in multiple versions


Sure, you want upgrade/update to update installonly pkgs too.

In any case 'dnf install' will work for locally downloaded kernel rpms,
which was your case right? so it should work as a workaround at least
for now, no?


the case of *that thread* was a ordinary "dnf upgrade" with no local 
packages involved


i think "for localupdate i switched back to yum-deprecated long ago, but 
for ordinary kernel updates pretend unsolved deps is simply 
unacceptable" was pretty clear - see the "but" - i gave up with dnf long ago





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Reindl Harald]

Am 18.01.2016 um 13:16 schrieb Jonathan Wakely:

And the fact that /var/log/dnf.rpm.log doesn't show updates done by PK
is just annoying. Isn't there a single log file I can look at to see
what was updated, and when?


currently no because dnf, PK and yum-deprecated using different logging 
instead just point to a generic "/var/log/packages.log" or how ever called


that's also annoying when you need to use yum-deprecated to get your 
tasks done, at least that and 
https://bugzilla.redhat.com/show_bug.cgi?id=1273925 could have been 
avoided (logwatch would have then contained the informations scratched 
with the premature logrotate)






signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Reindl Harald]

Am 18.01.2016 um 13:39 schrieb Heiko Adams:

Am Montag, den 18.01.2016, 12:27 + schrieb Jonathan Wakely:

On 18/01/16 07:05 -0500, Honza Šilhan wrote:

yes, autoremoval issue could be either caused by bad packaging [1]
or when you are
installing packages via yum or packagekit [2]. We are working on
better integration
between DNF and PK so this could be fixed soon. At the meantime use
this workaround [3].


It's a *terrible* workaround though. "Make a note of everything that
gets installed using PK and then as root run dnf to mark them as
userinstalled". A better workaround is "Don't use PK to install
things, use DNF". Why bother using PK at all if you then have to go
and run DNF commands for the same packages? You might as well just
use
DNF.

Because sometimes PK says there are updates available while "dnf update
--refresh" says no updates are available?
Happend to me several times in the past.


that's the drawback of dnf-makecache.timer because it may cache 
something shortly before updates are pushed and without that caching it 
would be refresehd when it's attempted to be used and so contain recent data


mask that timer and you are done
that never should have been introduced as default

the logflood "Cannot add dependency job for unit dnf-makecache.timer, 
ignoring: Unit dnf-makecache.timer is masked" should go away soon 
(referenced in a different thread and a systemd bugreport of some otehr 
person)




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

dnf still is unuseable

[Reindl Harald]

for localupdate i switched back to yum-deprecated long ago, but for 
ordinary kernel updates pretend unsolved deps is simply unacceptable


*no* i am not the only one - see karma comments for 4.3.3-300.fc23

https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14
https://bugzilla.redhat.com/show_bug.cgi?id=1271676

may i suggest to forget that dnf ever existed and switch back to yum?

ongoing problems in the core-task solve dependencies is not production 
ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and 
"yum-deprecated" until DNF is useable and provides the same capabilities 
as yum/yum-utils




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Reindl Harald]

Am 17.01.2016 um 23:54 schrieb Kevin Fenzi:

On Sun, 17 Jan 2016 23:27:02 +0100
Reindl Harald <h.rei...@thelounge.net> wrote:


for localupdate i switched back to yum-deprecated long ago, but for
ordinary kernel updates pretend unsolved deps is simply unacceptable

*no* i am not the only one - see karma comments for 4.3.3-300.fc23


But your comment doesn't explain what you are even doing.
What was the command and all output?


just "dnf upgrade" and DNF don't give any useful output, even not with 
"dnf -v upgrade" in the last case with *no local* packages



For localling installing new kernel versions, I use 'dnf install' and
it works just fine here.


"dnf update *.rpm" is the way which has to work


https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14
https://bugzilla.redhat.com/show_bug.cgi?id=1271676


This seems like a matter of taste. If you want to keep yearly logs, set
your logrotate that way.


AFAIR the config files are not config noreplace"


may i suggest to forget that dnf ever existed and switch back to yum?


You can suggest it, but it's not going to happen, so I'd advise
relaxing some and working with dnf developers.


what more than report bugs months ago which can be reprodcued with 
nearly every "dnf update *.rpm" when there are sub-packages with 
inter-dependencies


better adivse the dnf evelopers to work together with reporters and just 
try "dnf update *.rpm" which worked in case of "yum update *.rpm" forever



I'd encourage you to re-read our code of conduct
( https://getfedora.org/code-of-conduct ) and try and be more
respectful in bugs and here. We are all trying to improve things, lets
work together


in case of such obvious bugs this *is* resepectful



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Reindl Harald]

Am 18.01.2016 um 00:48 schrieb Kevin Fenzi:

On Mon, 18 Jan 2016 00:01:13 +0100
Reindl Harald <h.rei...@thelounge.net> wrote:

...snip...


"dnf update *.rpm" is the way which has to work


Why? It works fine as a install. It's installing a new kernel, since
kernels can have many versions installed at a time it makes more sense
for it to be a install than an upgrade (which would imply that the old
version would be removed).


why?

because you don't type "dnf install kernel" instead "dnf upgrade" and 
"kernel-headers" *is never installed* in multiple versions



https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14
https://bugzilla.redhat.com/show_bug.cgi?id=1271676


This seems like a matter of taste. If you want to keep yearly logs,
set your logrotate that way.


AFAIR the config files are not config noreplace"


The spec seems to have:
%config(noreplace) %{_sysconfdir}/logrotate.d/%{name}


well, give it a try, but for many years you had yum-logs for the 
complete year rotated once on the begin of a new year - package updates 
are not that often and don#t flood logs like some systemd things




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Reindl Harald]

Am 18.01.2016 um 00:08 schrieb Neal Gompa:

On Sun, Jan 17, 2016 at 6:01 PM, Reindl Harald <h.rei...@thelounge.net> wrote:



Am 17.01.2016 um 23:54 schrieb Kevin Fenzi:


I'd encourage you to re-read our code of conduct
( https://getfedora.org/code-of-conduct ) and try and be more
respectful in bugs and here. We are all trying to improve things, lets
work together



in case of such obvious bugs this *is* resepectful



No, it is not. Your tone and method of communication is highly
antagonistic in nature on both mailing lists and in bugs you've filed
in the Red Hat Bugzilla, and it's very hard to be willing to even
consider issues you experience when you continue to maintain such a
tone while trying to seek assistance or trying to get something fixed.


and replace a perfect working package manager is respectful to users?


Fedora is a large community and all of us love using and developing
the distribution. Passions may get a bit hot, but we should always be
respectful and constructive. We also don't live in isolation, and work
with other communities to develop excellent solutions that everyone
can use, including the many projects and products that are downstream
from Fedora.


dnf is far away from "excellent solutions"

just the fact that there are no useful outputs about the nature of a 
(mostly pretended) dependency problem disqualifies it while 
"yum-deprecated" shows you even soname-conflicts in a clear way


the case where i had enough again and wrote the mail above was a "dnf -v 
upgrade" with no useful output and "yum-deprecated upgrade" just worked 
fine as all the years ago - so *there is no* dependency problem



And if you really want something fixed that badly, talk to the DNF
development team about contributing to fix particular issues, or even
work with them one-on-one to help them fix it properly. Suggesting to
throw out DNF and re-instate Yum is not helpful and makes it really
easy to ignore you.


it would be enough to *remove* all that deprecation warnings for 
"yum-deprecated" and "package-cleanup" so that i could set an alias back 
to yum-deprecated




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Standard, consistent subject lines for automated emails

[Reindl Harald]

Am 16.01.2016 um 14:34 schrieb Richard W.M. Jones:

Here are a small collection of subject lines of emails sent
automatically to me by various Fedora systems in the past few days:

Subject: upgradepath PASSED for FEDORA-2015-850e89be8b
Subject: [Fedora Update] [comment] auto-buildrequires-1.2-1.fc23
Subject: rjones's libguestfs-1.33.1-2.fc24 completed
Subject: rpmlint PASSED for libguestfs-1.33.1-2.fc24
Subject: Broken dependencies: libguestfs
Subject: ABRT report for package gnome-boxes has reached 10 occurrences
Subject: [Bug 1269975] svirt very occasionally prevents parallel libvirt [..]
Subject: Fedora 'packager' sponsor needed for suanand
Subject: sailer's mingw-sqlite-3.10.1.0-1.fc24 failed to build
Subject: libguestfs's builds are back to normal in f24
Subject: dchen pushed to ocaml-lwt (el6).  "New upstream version 2.2.0."

The only consistent thing is there's nothing consistent about them :-/

I'd like to propose a very lightweight "standard" for subject lines of
emails.

(1) The first word should be the package name which the email
concerns


in context of that the subjects below needs to be fixed listing all 
subpackages and exceed TWO KILOBYTE subject header because place the 
package in front would prevent to see anything else (in case of other 
packages not exceeding 2048 byte but have subpackages too)


Jan  7 05:23:03 mail-gw postfix/cleanup[2859]: 3pbZDQ6RR5z2B: reject: 
header Subject: [Fedora Update] [CRITPATH] [comment] 
kf5-kdoctools-5.18.0-1.fc23 kf5-kdbusaddons-5.18.0-1.fc23 
kf5-kio-5.18.0-1.fc23 kf5-kjsembed-5.18.0-1.fc23 
kf5-ktextwidgets-5.18.0-1.fc23 kf5-kidletime-5. from 
bastion01.fedoraproject.org[209.132.181.2]; 
from= to= proto=ESMTP 
helo=: 5.7.1 Administrative Prohibition 
(Subject-Header Too Long)




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 16.01.2016 um 19:43 schrieb Gerald B. Cox:


On Sat, Jan 16, 2016 at 9:55 AM, Kevin Fenzi > wrote:

The benchmark if it's legal to include something in Fedora is
what Fedora Legal says.


I basically would agree with everything you stated, except I would
change the sentence to read:  "The benchmark if it's permissible..."
Fedora has it's own rules, but when you use the term "legal" the
connotation is that the other distributions which are distributing ZFS
are breaking the law


nonsense

if it comes to law topics in many cases 5 lawyers are coming up with 6 
opinions and every decision made has *nothing* to do with any other party



Fedora cannot make that determination


it don't make it for others
it just makes it for Fedora

if Redhat legal says "no" to be on the safe side that has *nothing* to 
do with any otehr distribution



blanket statements like that lead to FUD and misquotes.
If Fedora chooses not to distribute ZFS for any reason, that is
perfectly fine - however, the fact
that we choose not to do so doesn't make it illegal


see above

and now please *stop* this topic
ZFS and external kmods don't make it to Fedora
suck it!



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 16.01.2016 um 22:07 schrieb Neal Gompa:

On Sat, Jan 16, 2016 at 3:00 PM, Chris Murphy  wrote:

On Sat, Jan 16, 2016 at 12:39 PM, Luya Tshimbalanga
 wrote:

Does Oracle include ZFS in their ISO by default?


No, and as far as I know they don't contribute to ZFS on Linux. There
is a distinction between ZFS and OpenZFS that's kinda important. ZFS
on Linux is based on OpenZFS, not ZFS. There're incompatible features
since pool version 28 in each, so they're essentially diverging. I
don't know if that qualifies them as defacto forks (either from each
other, or from ZFS pool version 28). Anyway, Oracle only includes ZFS
in Solaris. And they continue to contribute to Btrfs.


They do, however, include DTrace in their distribution, which remains
CDDL licensed in their distribution


stop that FUD - CDDL is not the problem - MIXING is the topic
and don't bring "cdrecrord" to the topic, the author is the problem

back to topic:
even if DTrace would be closed source Oracle could include it because 
tehy are the *copyright holder* and can release it under *every* license 
they like to do





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 16.01.2016 um 22:19 schrieb Neal Gompa:

On Sat, Jan 16, 2016 at 4:18 PM, Reindl Harald <h.rei...@thelounge.net> wrote:



Am 16.01.2016 um 22:07 schrieb Neal Gompa:


On Sat, Jan 16, 2016 at 3:00 PM, Chris Murphy <li...@colorremedies.com>
wrote:


On Sat, Jan 16, 2016 at 12:39 PM, Luya Tshimbalanga
<l...@fedoraproject.org> wrote:


Does Oracle include ZFS in their ISO by default?


No, and as far as I know they don't contribute to ZFS on Linux. There
is a distinction between ZFS and OpenZFS that's kinda important. ZFS
on Linux is based on OpenZFS, not ZFS. There're incompatible features
since pool version 28 in each, so they're essentially diverging. I
don't know if that qualifies them as defacto forks (either from each
other, or from ZFS pool version 28). Anyway, Oracle only includes ZFS
in Solaris. And they continue to contribute to Btrfs.


They do, however, include DTrace in their distribution, which remains
CDDL licensed in their distribution


stop that FUD - CDDL is not the problem - MIXING is the topic
and don't bring "cdrecrord" to the topic, the author is the problem

back to topic:
even if DTrace would be closed source Oracle could include it because tehy
are the *copyright holder* and can release it under *every* license they
like to do


DTrace is a kernel module that is CDDL licensed in Oracle Linux. So, not FUD


come on get a laywer and dicuss that topic somewhere else

first they laywer needs to find out *which* of both licenses maybe 
violated - if it's the CDDL then it's no problem for Oracle, if it's the 
GPL, well it needs a lawsuit in doubt


IT DOES NOT MATTER what Oracle does
IT DOES NOT MATTER what anybody else does
ABOVE DOES NOT MATTER for Fedora

licensing is a minefield and hence Fedora / Redhat legal stays on the 
SAVE SIDE - so WHAT needs to be discussed again and again


and since you still did not realize it:
even without the legal questions a out-of-tree module WON'T make it into 
Fedora and so the whole topic is done






signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 16.01.2016 um 20:51 schrieb Gerald B. Cox:

On Sat, Jan 16, 2016 at 11:35 AM, Kevin Fenzi > wrote:

I can't image anyone misinterpreting my statement that way, but yes, I
was not trying to suggest anything anyone else does is legal or not,
simply that any inclusion in Fedora would need approval of Fedora legal
and continuing to post about it or speculate is just a waste of time.

ROFL... you know the internet Kevin... and any conspiracy theory can and
will be
propagated... but I didn't believe you intended to imply that...


hence the next time as Fedora legal directly instead repeat the same 
discussion again (it's not the first time this topic appeared) where 
people in the thread even point to "Oracle Linux" with "but they do too" 
while Orcale holds all copryrights and patents in ZFS after buyed Sun 
long ago




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Cannot add dependency job for unit dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked

[Reindl Harald]

Am 15.01.2016 um 03:38 schrieb Zbigniew Jędrzejewski-Szmek:

On Thu, Jan 14, 2016 at 10:17:54PM +0100, Reindl Harald wrote:

WHO defines that "dependency" and WHY?

when i say "mask, i want it refreshed when it is used" than *i mean*
that and there is no business to spit my logs on all machines al day
long full with "you have masked it"

Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for
unit dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is
masked.


It's fixed upstream, should go out in the next systemd update for F23:
https://github.com/systemd/systemd/pull/2076
https://bugzilla.redhat.com/show_bug.cgi?id=1278264


thank you!





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 14.01.2016 um 16:56 schrieb Neal Gompa:

I've recently been wondering why we haven't allowed kernel module
packages in Fedora since Fedora 8. I've tried searching through our
wiki and the mailing list, but I haven't come up with any concrete
reasons for why we disallow them.

If it is perhaps the issue of keeping things in sync with kernels we
provide (that is, maintainers didn't/couldn't keep up with new kernels
being pushed during a release cycle), then I think the situation has
changed.

We have two tools that can help us in this regard: akmod and Koschei,
both came after our policy change to disallow kernel modules.


akmod is a dirty hack and fails often enough for rpmfusion stuff

additionally you should *never* need GCC and devel packages installed on 
a normal enduser system for a ton of reasons




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 14.01.2016 um 18:05 schrieb Neal Gompa:

On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald <h.rei...@thelounge.net> wrote:


Am 14.01.2016 um 16:56 schrieb Neal Gompa:

We have two tools that can help us in this regard: akmod and Koschei,
both came after our policy change to disallow kernel modules.


akmod is a dirty hack and fails often enough for rpmfusion stuff

additionally you should *never* need GCC and devel packages installed on a
normal enduser system for a ton of reasons


The most common reason that akmod fails is the same reason dkms often
fails: the correct kernel-devel isn't installed. For whatever reason,
there's no logic in DNF to handle this case properly. Of course, to be
fair, this problem happens in Yum too, but since Yum isn't actively
supported in Fedora anymore, it's not as much of a concern.


no, the most common reason is that whatever should don't build aganinst 
a recent fedora kernel




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 15.01.2016 um 01:07 schrieb Neal Gompa:

On Thu, Jan 14, 2016 at 6:54 PM, Stephen John Smoogen <smo...@gmail.com> wrote:

On 14 January 2016 at 12:20, Neal Gompa <ngomp...@gmail.com> wrote:

On Thu, Jan 14, 2016 at 2:14 PM, Reindl Harald <h.rei...@thelounge.net> wrote:

who is "Lawrence Livermore"?



Lawrence Livermore National Laboratory is an organization founded by
the University of California to do research and development for
academic and government purposes. The US Department of Energy
commissioned them to port ZFS to Linux quite a long time ago[0], which
is the foundation of the current ZFS on Linux codebase.

Please do some research before actually saying things.


Might be good if you did also :).

Lawrence Livermore National Laboratory is a US Government/Department
of Energy laboratory that UC Berkeley has a hand in managing. It was
not founded by the University of California but came out of the post
Manhatten project to build the hydrogen bomb. The US DOE did not
commission the lab to make the port. The port was done as part of a
project to have a large scale filesystem work for certain computer
clusters. That work got special permission from Sun but those
permissions look to be sealed.

Just because a port was done and then released does not mean that
Lawrence Livermore is using it in any large way etc. There are
thousands of projects that come out of these labs which maybe 3-20
students, grad students and phd's worked on but aren't in any use.
Most of them will get that file attached to them which doesn't mean
that LLNL sactioned it, DOE commission it etc etc. It just means that
it was done at the lab as part of some project and the law requires
that the file is attached to it.


LLNL is still actively involved in the ZFS on Linux project, so they
are still doing something with it


that don't make them to a general purpose Linux distibution which as the 
whole point of "who is "Lawrence Livermore?"




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 15.01.2016 um 01:07 schrieb Andrew Lutomirski:

On Thu, Jan 14, 2016 at 4:01 PM, Reindl Harald <h.rei...@thelounge.net> wrote:

Am 15.01.2016 um 00:36 schrieb Andrew Lutomirski:


If, for example, it simply installed into
/lib/modules/VERSION/akmod/path/to/driver.ko, then rpm could be taught
to delete /lib/modules/VERSION when the corresponding kernel package
goes away (either using a scriptlet in the kernel package or an RPM
trigger, I imagine), and everything would work nicely without
injecting extra rpms into the system



rpm's remove files and folders they installed

if that folders are not empty because foreign files that files and the
folders will stay afetr remove - there is no "but" - it is unacceptable when
a package purges a whole folder due removal because you can't know what and
why the user stored there

any package doing such craft would need to be fixed
so don't propose any package should start such black magic


I'll ask again: can you please think just a little bit before
arbitrarily objecting to things people suggest on this list?


i think more than just a little bit


Suppose that the removal of kernel-core-4.3.3-300.fc23.x86_64
automatically deleted everything in
/lib/modules/4.3.3-300.fc23.x86_64/akmods.  What, if anything, would
go wrong?  I'm serious.  That folder would exist for the /specific
purpose/ of being unlinked when the matching kernel goes away


it is not part of the kernel and there is no business to include 
*arbitrarily* fuzzy logic in a package because other 3rd party scripts 
could have stored something there which might be removed


*especially* not in the kernel package



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 14.01.2016 um 19:54 schrieb Neal Gompa:

On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb  wrote:

On 01/14/2016 07:56 AM, Neal Gompa wrote:


Aside from the DNF issue, is there anything else I'm missing in
relation to kmods in Fedora?


If you have secure boot, you have to go through the process to sign the
kernel modules you build and register the key with the boot system.


That would be something our build system (Koji, etc.) would handle if
we allowed them again, right? After all, I believe Koji handles our
kernel signing, too.


how do you imagine in real life maintaining kmod's by different people 
and maintaining the kernel by others?


there are often timeframes where you get each week and in rare cases 
twice a week a kernel update - have fun to coordinate that!


and *no* hold back kernel updates for crap hardware not supported by the 
mainline kernel or burden the kernel package-maintainer the additional 
work is no solution


i don't want to get my kernel pushed with a delay because of other 
packages i don't care because a few users don#t think before by computers




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 14.01.2016 um 20:20 schrieb Neal Gompa:

On Thu, Jan 14, 2016 at 2:14 PM, Reindl Harald <h.rei...@thelounge.net> wrote:


Am 14.01.2016 um 19:57 schrieb Gerald B. Cox:


On Thu, Jan 14, 2016 at 10:45 AM, Bill Nottingham <nott...@splat.cc
<mailto:nott...@splat.cc>> wrote:

 As a rule, I try not to take legal licensing interpretations from a
CTO
 who's trying to sell me the thing they're talking about the
 licensing of.

 We certainly could send that interpretation of CDDL/GPL and the
 kernel to the
 legal team... but I'm not sure they'd agree with it.

Well, if Lawrence Livermore is doing it, and Canonical apparently plans
to do it, it probably would be a good idea to get a determination from
the legal team


who is "Lawrence Livermore"?


Lawrence Livermore National Laboratory is an organization founded by
the University of California to do research and development for
academic and government purposes. The US Department of Energy
commissioned them to port ZFS to Linux quite a long time ago[0], which
is the foundation of the current ZFS on Linux codebase.


and they build a large, genral purpose, linux distribution?


Please do some research before actually saying things


likely i did much more research than you can even imagine long before 
that thread started


CDDL is incompatible with GPLv2 - period



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 14.01.2016 um 19:57 schrieb Gerald B. Cox:

On Thu, Jan 14, 2016 at 10:45 AM, Bill Nottingham > wrote:

As a rule, I try not to take legal licensing interpretations from a CTO
who's trying to sell me the thing they're talking about the
licensing of.

We certainly could send that interpretation of CDDL/GPL and the
kernel to the
legal team... but I'm not sure they'd agree with it.


Well, if Lawrence Livermore is doing it, and Canonical apparently plans
to do it, it probably would be a good idea to get a determination from
the legal team


who is "Lawrence Livermore"?

is Canonical located in the US? no!
is Redhat located in the US? yes!
you see the difference?

https://en.wikipedia.org/wiki/GNU_General_Public_License

ZFS cannot be included in the GPL-licensed Linux kernel, because it is 
licensed under the GPL-incompatible CDDL


PERIOD



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 14.01.2016 um 20:15 schrieb Gerald B. Cox:


On Thu, Jan 14, 2016 at 10:57 AM, Gerald B. Cox > wrote:

On Thu, Jan 14, 2016 at 10:45 AM, Bill Nottingham > wrote:

As a rule, I try not to take legal licensing interpretations
from a CTO
who's trying to sell me the thing they're talking about the
licensing of.

We certainly could send that interpretation of CDDL/GPL and the
kernel to the
legal team... but I'm not sure they'd agree with it.

Well, if Lawrence Livermore is doing it, and Canonical apparently
plans to do it, it probably would be a good idea to get a
determination from the legal team.  I don't care one way or another,
I use BTRFS - but we shouldn't be saying there are license issues if
there aren't.

I also found this: https://wiki.ubuntu.com/ZFS
ZFS is licensed under the CDDL , a
popular and widely used OSI-approved open source license
, that is recognized by the FSF
 as a free software
license, but is incompatible with the GNU GPL. Because of that ZFS
cannot be added to the Linux kernel directly. It can, however, be
distributed as a DKMS package separate from the main kernel package


oh yeah - bring a DKMS package out of tree *for your filesystems* in the 
mix and wait for bugreports of users in trouble


do it at your own - but don't expect it a good idea for a general 
purpose distribution and *no* "but others do" is no valid justification




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 14.01.2016 um 20:34 schrieb Gerald B. Cox:


On Thu, Jan 14, 2016 at 11:14 AM, Reindl Harald <h.rei...@thelounge.net
<mailto:h.rei...@thelounge.net>> wrote:


ZFS cannot be included in the GPL-licensed Linux kernel, because it
is licensed under the GPL-incompatible CDDL


Harald, you missed the point


you missed the point


We all understand it cannot be included
in the kernel - we're talking about whether or not it can be included in
the distribution.  Fedora already includes software that has
incompatible GPL licenses...


but you don't understand "derived work" which affects kernel modules


https://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses

In fact, the CDDL is an approved Fedora license:
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing


a standalone software with CDDL is a different topic


Just because something is incompatible with the GPL doesn't in and of
itself blacklist it from being included in the distribution


no, but when you link that incompatible code with the kernel which is 
GPLv2 code it's a complete different topic


for "out of tree kernel modules" just read the other thread



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 14.01.2016 um 19:45 schrieb Bill Nottingham:

Bill, your maildomain is burned and the only reason that your mails 
appear here is there the mailing list is whitelisted based on SPF


1.5
URIBL_SBL_A Contains URL's A record listed in the
SBL blocklist [URIs: splat.cc]  

1.5
URIBL_SBL Contains an URL's NS
IP listed in the SBL blocklist  [URIs: splat.cc]

7.0 URIBL_BLACK
Contains an URL listed in the URIBL blacklist   
[URIs: splat.cc]

-100 USER_IN_SPF_WHITELIST From: address is in the user's SPF whitelist



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Reindl Harald]

Am 15.01.2016 um 00:36 schrieb Andrew Lutomirski:

If, for example, it simply installed into
/lib/modules/VERSION/akmod/path/to/driver.ko, then rpm could be taught
to delete /lib/modules/VERSION when the corresponding kernel package
goes away (either using a scriptlet in the kernel package or an RPM
trigger, I imagine), and everything would work nicely without
injecting extra rpms into the system


rpm's remove files and folders they installed

if that folders are not empty because foreign files that files and the 
folders will stay afetr remove - there is no "but" - it is unacceptable 
when a package purges a whole folder due removal because you can't know 
what and why the user stored there


any package doing such craft would need to be fixed
so don't propose any package should start such black magic

well, that affects me too because VMware workstation modules but it's my 
job and not the business of the kernel package




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Cannot add dependency job for unit dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked

[Reindl Harald]

WHO defines that "dependency" and WHY?

when i say "mask, i want it refreshed when it is used" than *i mean* 
that and there is no business to spit my logs on all machines al day 
long full with "you have masked it"


Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:02 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:02 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:03 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:03 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:13 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:13 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:32:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:33:20 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:34:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:34:22 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:35:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:36:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:38:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:40:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:40:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:40:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:42:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:44:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:45:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:45:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:46:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:48:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:50:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:50:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:50:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:52:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:54:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:55:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:56:01 localhost systemd[1]: Cannot add dependency job for unit 
dnf-makecache.timer, ignoring: Unit 

Re: kmods and Fedora

[Reindl Harald]

Am 14.01.2016 um 20:09 schrieb Neal Gompa:

On Thu, Jan 14, 2016 at 2:00 PM, Josh Boyer  wrote:

On Thu, Jan 14, 2016 at 1:54 PM, Neal Gompa  wrote:

On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb  wrote:

On 01/14/2016 07:56 AM, Neal Gompa wrote:


Aside from the DNF issue, is there anything else I'm missing in
relation to kmods in Fedora?


If you have secure boot, you have to go through the process to sign the
kernel modules you build and register the key with the boot system.


That would be something our build system (Koji, etc.) would handle if
we allowed them again, right? After all, I believe Koji handles our
kernel signing, too.


No, it would not.

The kernel modules are signed with an ephemeral cert as part of the
kernel build process.  They are not signed with the Fedora cert used
for Secure Boot.  The vmlinuz and grub2 binaries are signed with the
Secure Boot cert.  The tool that does the signing only works with
PECoff binaries and the kernel modules are not PECoff.

So no, the build system does not support signing modules outside of
the normal kernel build.


So that would mean in order to make kernel modules build to work
outside of the kernel build process, we would need a way to add more
certs that would be accepted by the kernel and grub, right? I assume
you'd want to do the ephemeral cert process for kmod builds too?


it is not supported by the kernel maintainers for a lot of reasons
accept it or become "the kernel maintainers"



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 14.01.2016 um 20:35 schrieb Michael Catanzaro:

On Thu, 2016-01-14 at 20:24 +0100, Reindl Harald wrote:

likely i did much more research than you can even imagine long
before
that thread started


I find this challenging to believe.


i don't care what you believe


CDDL is incompatible with GPLv2 - period


Did you read the web site at all? The argument is that it can be used
as a kernel module without constituting a derived work. Many developers
believe this is not a GPL violation. Many believe otherwise. This is a
well-known, open controversy. It's to be expected that different sets
of lawyers will have different opinions on the risk depending on
business requirements and their company's risk profile.


and Redhat legal decided against
now you!



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ELF arch question

[Reindl Harald]

Am 14.01.2016 um 15:42 schrieb Orion Poplawski:

I want BLAS/LAPACK implementations to do something like:

%if 
Provides: libblas.so.3()(64bit)
%else
Provides: libblas.so.3
%endif


not sure why you think you need to specify that explicitly while 
rpmbuild does that on it's own, but anyways, you would likely use 
soemthing like that


libblas.so.3%{?_isa}

https://fedoraproject.org/wiki/Packaging:Guidelines
and look for %{?_isa} there as well as 
http://www.rpm.org/wiki/PackagerDocs/ArchDependencies





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Announce of package to mark as Orphan – repoview – rpmdepsize – snake - revisor

[Reindl Harald]

Am 13.01.2016 um 01:25 schrieb Nico Kadel-Garcia:

On Fri, Jan 8, 2016 at 10:37 AM, Sérgio Basto  wrote:

On Sex, 2016-01-08 at 08:54 -0500, Jaroslav Mracek wrote:

Hi everybody,

I would like to set following packages as Orphan due to that upstream
is dead or  maintainers do not respond:

repoview


have we a replace for repoview ?


Does anyone actually like it? I find it to be confusing eye candy,
unnecessary and interfering with basic content reviews, compared to a
flat filename based file list. I deliberately exclude "repoview" from
all repository mirrors


yes, for all internal repos as well as for the cache repo on the 
adminserver which deploys updates from dnf-cache to all other servers




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Reindl Harald]

Am 13.01.2016 um 14:01 schrieb Florian Festi:

On 01/11/2016 09:06 PM, Richard W.M. Jones wrote:

On Mon, Jan 11, 2016 at 03:46:27PM +0100, Jan Kurik wrote:

= Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
https://fedoraproject.org/wiki/Changes/NewRpmDBFormat


Details of the format?

What forward and backward compatibility guarantees are there?


RPM will keep support for BDB for now. But to get rid of the dependency
it will be dropped at some point in the future. So it will stay backward
compatible.

The file format is clearly not forward compatible (although you will be
for now be able to still use the old format)


"clearly not forward compatible"?

there needs to be a migration path to get a existing bdb rpmdb converted 
our you will blow with "will be dropped at some point in the future" a 
ton of users and admins to hell


we run 30 machines originally installed with Fedora 9 and updated until 
now to F23 which surived UsrMove, migration to grub2 including make 
space for grub2 on the bootdrive with parted and the switch to systemd 
without install them from scratch


so there is no justification to declare one need to install from scratch 
just because rpm which works for many years fine changes it's storage 
format




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Reindl Harald]

Am 13.01.2016 um 14:30 schrieb Richard Hughes:

On 13 January 2016 at 13:13, Reindl Harald <h.rei...@thelounge.net> wrote:

so there is no justification to declare one need to install from scratch
just because rpm which works for many years fine changes it's storage format


I don't think anyone said there was a need to reinstall from scratch


so how do you translate "clearly not forward compatible"?



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Reindl Harald]

Am 12.01.2016 um 09:22 schrieb Muayyad AlSadi:

 nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
 -cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT"
2>&1 < /dev/null &
 if [ $? -eq 0 ]
...
 /bin/echo -n $! > "$ZOOPIDFILE"

so I believe the forking is done by bash without a ready socket.

@Reindl.Harald the above bash is doing the fork, without any listening
socket. so it's not guessing


the problem here is the bash script wrapped around



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Reindl Harald]

Am 12.01.2016 um 19:30 schrieb Lennart Poettering:

On Tue, 12.01.16 18:54, Reindl Harald (h.rei...@thelounge.net) wrote:


Also, what happens if the daemon is configured to listen on some
different port? Or on multiple ports? Are you parsing the daemon's
config file too to figure out what to watch for? YUCK!


the Fedora myqld unit does, mine is simplified

the systemd-behavior that manual "systemctl stop whatever.service" don't
prevent socket activation and fireup again the service is a systemd problem
*you* have to solve if you want widely adopted usage of socket activation


That's hardly a "problem", as I see it.


for you


What you should be invoking is "systemctl stop whatever.socket
whatever.service", which terminates both the daemon and the listening
socket. I think that's pretty easy to grok for most folks, as long as
you realized the logic behind it once.


it's not a matter of grok something

it's a matter of not every daemon has a socket and hwat does the user 
express with a command - you aregued the same way about making 
"systemctl stop sshd" versus "systemctl stop sshd.service" work as default



That said, of course, this is not obvious at first, hence since quite
some time "systemctl stop" will actually explain this to you: if you
stop a daemon, but leave its socket running, then you'll get a
friendly message telling you about this, and suggesting you the right
command line to terminate the socket too.


as soon as you are able to print out such a "friendly message" you are 
also able to imply it automatically



I am pretty sure this makes a lot of sense the way it is, and is
sufficiently well self-explanatory.


no, it violates the prnciple of least surprise and that won't change



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Reindl Harald]

Am 12.01.2016 um 19:44 schrieb Lennart Poettering:

On Tue, 12.01.16 19:37, Reindl Harald (h.rei...@thelounge.net) wrote:


That said, of course, this is not obvious at first, hence since quite
some time "systemctl stop" will actually explain this to you: if you
stop a daemon, but leave its socket running, then you'll get a
friendly message telling you about this, and suggesting you the right
command line to terminate the socket too.


as soon as you are able to print out such a "friendly message" you are also
able to imply it automatically


Well, sure, but that's something we don't want to do, as people should
be able to stop units and their triggering units separately and
individually.

I'd be willing to take a patch that adds a new job mode though, that
recursively includes stop/start jobs for all triggering
units. i.e. "systemctl --job-mode=triggering foo.service" or so. That
would certainly be a useful enhancement, but should not be the
default.


IT SHOULD be the default

when i say "systemctl stop service" i mean that unconditionally and 
there is no point in for example stop a webserver manually while the 
socket would fire up the service on the next request


there is *really* no point for such a behavior


I am pretty sure this makes a lot of sense the way it is, and is
sufficiently well self-explanatory.


no, it violates the prnciple of least surprise and that won't change


Well, let's agree to disagree on this one


well, than accept that i refuse to use socket activated services and 
recommend that to anybody else until bheavior changes




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Reindl Harald]

Am 12.01.2016 um 17:41 schrieb Lennart Poettering:

On Tue, 12.01.16 17:16, Muayyad AlSadi (als...@gmail.com) wrote:


well. But if you can double fork() in Java you should be fine and can


it seems that zookeeper is doing the fork in the bash script using nohub
not in java


when it finished setting up its listening socket. You cannot script


typically I loop using "lsof" or "nc"


Such sleep loops are ugly and a hack. It would be much better to fix
this properly with a clean notification.

Doing such sleep loops will just help keeping up java's bad rep for
being slow...

Also, what happens if the daemon is configured to listen on some
different port? Or on multiple ports? Are you parsing the daemon's
config file too to figure out what to watch for? YUCK!


the Fedora myqld unit does, mine is simplified

the systemd-behavior that manual "systemctl stop whatever.service" don't 
prevent socket activation and fireup again the service is a systemd 
problem *you* have to solve if you want widely adopted usage of socket 
activation




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Reindl Harald]

Am 12.01.2016 um 19:50 schrieb Lennart Poettering:

On Tue, 12.01.16 19:48, Reindl Harald (h.rei...@thelounge.net) wrote:




Am 12.01.2016 um 19:44 schrieb Lennart Poettering:

On Tue, 12.01.16 19:37, Reindl Harald (h.rei...@thelounge.net) wrote:


That said, of course, this is not obvious at first, hence since quite
some time "systemctl stop" will actually explain this to you: if you
stop a daemon, but leave its socket running, then you'll get a
friendly message telling you about this, and suggesting you the right
command line to terminate the socket too.


as soon as you are able to print out such a "friendly message" you are also
able to imply it automatically


Well, sure, but that's something we don't want to do, as people should
be able to stop units and their triggering units separately and
individually.

I'd be willing to take a patch that adds a new job mode though, that
recursively includes stop/start jobs for all triggering
units. i.e. "systemctl --job-mode=triggering foo.service" or so. That
would certainly be a useful enhancement, but should not be the
default.


IT SHOULD be the default


Well, no. And spelling this out in caps won't help.

This is nothing we can just change, even if we'd want to. It's exposed
stable behaviour.

Sorry


surely, you could in systemd recognize that the socket is ignored for 
now, automatically started with the next "systemctl start service"


there is a huge difference between

* socket enabled, service not running
* socket enabled, service stopped by the admin

in case 1 it's exposed behavior to start the service on the first 
request, in case 2 it's the explicit wish of the admin SHUT DOWN a 
service - with the still enabled and listening socket that wish is worth 
*nothing* because there is no difference between a running netwrok 
waware service or a stopped one with a listening socket fire it up by 
the first request


"systemctl stop service" in fact does *nothing*

what makes that beavior worst is that "systemctl stop service.service 
service.socket" enorces the admin not just start the service after 
maintain operatins - he needs also to start the socket


a "systemctl stop service" with implicit stop the socket and after 
maintainence "systemctl start service" autmatically start the socket if 
it was implicit stopped would be the desired behavior for anybody in 
real life




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Reindl Harald]

Am 12.01.2016 um 16:09 schrieb Lennart Poettering:

On Tue, 12.01.16 15:57, Reindl Harald (h.rei...@thelounge.net) wrote:



Am 12.01.2016 um 15:45 schrieb Lennart Poettering:

On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote:



@Lennart Poettering is there a way to use something like "ExecStartPost="
do the the notify with type=simple?


When would you even call that? Somehow your Java app needs to report
when it finished setting up its listening socket. You cannot script
around that fact


at the same point as for mariadb /  mysql


...

  usleep 10

...

Polling around a 1s sleep loop. That's a gross hack


besides that 10 us are hardly a second (the fedora build afaik is 
using a sleep 1) it works the last 5 years perfectly and "You cannot 
script around that fact" is wrong if you like it or not






signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: unsubscribe

[Reindl Harald]

WTF

List-Unsubscribe:





Am 12.01.2016 um 16:52 schrieb Paddy Walker:

Unsubscribe

On 12/01/16 15:47, John Lockman wrote:




signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Reindl Harald]

Am 11.01.2016 um 14:06 schrieb Muayyad AlSadi:

hi,

in fedora's zookeeper service < /usr/lib/systemd/system/zookeeper.service
we have the following line

ExecStart=/usr/bin/zkServer.sh start zoo.cfg

why not

ExecStart=/usr/bin/zkServer.sh start-foreground zoo.cfg

of type simple

specially that file does not contain "PIDFile=" directive


type simple don't come without drawbacks
depending service shave *no idea* if it is ready

the "clamd" service as example comes with "Type = simple" which means 
when you are using clamav-milter you get at boot a ton of warnings while 
"Type=forking" implies that depending services are started *after* the 
forking and the service is *really* read (it needs depending on the 
signatures a longer time for initalization)




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Reindl Harald]

Am 11.01.2016 um 14:32 schrieb Muayyad AlSadi:

"Type=forking" implies that depending services are started *after* the forking 
and the service is *really* read (it needs depending on the signatures a longer time for 
initalization)


but I guess it needs a PID file path to work properly which is not the case


*nothing* needs a PID file path because systemd knows the main-PID since 
it's a supervisor - in fact for most services throwing warnings because 
the pid-file the solotuin from F15 until now was clone the systemd-unit 
below /etc/systemd/system/ and remove the line



[root@mail-gw:~]$ systemd-analyze blame | grep clamd
 10.750s clamd.service


[root@mail-gw:~]$ systemctl status clamd
  clamd.service - ClamAV Scanner Daemon
   Loaded: loaded (/etc/systemd/system/clamd.service; enabled; vendor 
preset: disabled)
   Active: active (running) since Di 2015-12-22 12:40:33 CET; 2 weeks 6 
days ago

 Main PID: 5402 (clamd)
   CGroup: /system.slice/clamd.service
   ??5402 /usr/sbin/clamd -c /etc/clamd.d/scan.conf


[root@mail-gw:~]$ cat /etc/systemd/system/clamd.service
[Unit]
Description=ClamAV Scanner Daemon

[Service]
Type=forking
Environment="TMPDIR=/tmp"
Environment="LANG=en_GB.UTF-8"
ExecStart=/usr/sbin/clamd -c /etc/clamd.d/scan.conf
ExecReload=/usr/bin/kill -HUP $MAINPID
Restart=always
RestartSec=1
Nice=5

User=clamscan
Group=clamilt

PrivateTmp=yes
PrivateDevices=yes
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_KILL
RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 AF_IPX 
AF_NETLINK AF_PACKET AF_X25

SystemCallArchitectures=x86-64

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Reindl Harald]

Am 11.01.2016 um 15:37 schrieb Michal Schmidt:

On 01/11/2016 02:58 PM, Reindl Harald wrote:

Am 11.01.2016 um 14:32 schrieb Muayyad AlSadi:

"Type=forking" implies that depending services are started
*after* the forking and the service is *really* read (it needs
depending on the signatures a longer time for initalization)


but I guess it needs a PID file path to work properly which is not
the case


*nothing* needs a PID file path because systemd knows the main-PID
since it's a supervisor


systemd cannot always guess which PID is the main PID of the service,
so with Type=forking it's good to use PIDFile=


every service in the last years which logged warnings about PIDFile 
while working fine was fixed here by remove that line


the main PID is the PID after the double-fork



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Reindl Harald]

Am 11.01.2016 um 17:26 schrieb Kalev Lember:

On 01/11/2016 03:46 PM, Jan Kurik wrote:

= Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
https://fedoraproject.org/wiki/Changes/NewRpmDBFormat

Change owner(s):
* Florian Festi < ffesti AT redhat DOT com >


Change format of the RPM Database from Berkeley DB to RPM's own format.

== Detailed Description ==
The current implementation of the RPM Database is based on Berkeley
DB. There are doubts about the its future and level of maintenance. In
addition rpm's use of the database has multiple issues on its own. As
a result RPM upstream is working to replace the database format with a
new implementation.


Is the new database going to be able to support yumdb use cases as well?
Might be a good time to get rid of separate rpmdb and yumdb and merge
them together.


please don't do that

the yumdb is bloat because it contains a endless history and that's 
growing on machines after 10, 20 or more dist-upgrades while currently 
it's easy to get rid of that bload by just rm -rf /var/lib/yum/* and/or 
rm -rf /var/lib/dnf/*




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Reindl Harald]

Am 11.01.2016 um 17:30 schrieb Muayyad AlSadi:

quoted from systemd.serivce manual page

 >> it is recommended to also use the PIDFile= option, so that systemd
can identify the main process of the daemon.

my point is that having a child double forked does not mean Zookeeper
TCP port is ready which is as bad as simple


is that just guessing or proven?




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Reindl Harald]

Am 11.01.2016 um 17:33 schrieb Neal Gompa:

On Mon, Jan 11, 2016 at 11:31 AM, Reindl Harald <h.rei...@thelounge.net> wrote:


Am 11.01.2016 um 17:26 schrieb Kalev Lember:


On 01/11/2016 03:46 PM, Jan Kurik wrote:


= Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
https://fedoraproject.org/wiki/Changes/NewRpmDBFormat

Change owner(s):
* Florian Festi < ffesti AT redhat DOT com >


Change format of the RPM Database from Berkeley DB to RPM's own format.

== Detailed Description ==
The current implementation of the RPM Database is based on Berkeley
DB. There are doubts about the its future and level of maintenance. In
addition rpm's use of the database has multiple issues on its own. As
a result RPM upstream is working to replace the database format with a
new implementation.



Is the new database going to be able to support yumdb use cases as well?
Might be a good time to get rid of separate rpmdb and yumdb and merge
them together.


please don't do that

the yumdb is bloat because it contains a endless history and that's growing
on machines after 10, 20 or more dist-upgrades while currently it's easy to
get rid of that bload by just rm -rf /var/lib/yum/* and/or rm -rf
/var/lib/dnf/*


If they were merged, I suspect they'd add a command for cleaning up
history that you could use


i also would have suspected that dnf and it's "lowlevel" libraries are 
using librpm and looking at that thread libsolv is accessing the 
database directly


as well i would have suspected that /var/lib/yum/ get some cleanup until 
i had enough by "locate fc12" find a ton of files with the history of 
all updates from intsrducing the yumdb on a F15 system


so i don't give anything about "suspect"





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Stop please

[Reindl Harald]

Am 09.01.2016 um 19:36 schrieb Michael Catanzaro:

On Fri, 2016-01-08 at 08:53 -0500, Mark Bidewell wrote:

Unfortunately GMail's web interface does not seem to recognize those
headers :(.  So a fair number of uses will have issues.


I, Michael Catanzaro, have never in my entire life seen any email
client display mail headers. It's beyond unreasonable to suggest users
look there for anything, much less for a way to unsubscribe from a
mailing list


well, because MUA's implement all sort of crap instead *useful* 
functions, otherwise *any* MUA would have a "reply-list" and 
"unsubscribe-list" button based on th email headers


https://addons.mozilla.org/En-us/thunderbird/addon/unsubscribe-from-mailing-list/

*any* proper mailing-list system is sending that headers
https://www.ietf.org/rfc/rfc2369.txt




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Stop please

[Reindl Harald]

Am 09.01.2016 um 19:46 schrieb Sudhir Khanger:

On Saturday 09 Jan 2016 12:36:08 PM Michael Catanzaro wrote:

I, Michael Catanzaro, have never in my entire life seen any email
client display mail headers. It's beyond unreasonable to suggest users
look there for anything, much less for a way to unsubscribe from a
mailing list.


That's very hard to believe. You may have over looked it. There are at least 2
places if not more where source of an email is available in KMail. View>Source
or right-click email>Source or via shortcut V.


it's possible in nearly any mail client
many have even options to show them always

http://www.list-unsubscribe.com/

https://answers.stanford.edu/solution/how-view-full-email-headers

https://support.apple.com/kb/PH19118?viewlocale=en_US=de_AT

http://email.about.com/od/mozillathunderbirdtips/qt/How-to-View-Complete-Message-Headers-in-Mozilla-Thunderbird.htm

https://support.office.com/en-in/article/View-e-mail-message-headers-cd039382-dc6e-4264-ac74-c048563d212c





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Stop please -> mailto:devel-le...@lists.fedoraproject.org

[Reindl Harald]

Am 08.01.2016 um 05:34 schrieb Michael Catanzaro:

On Thu, 2016-01-07 at 21:27 -0700, Byron Steele wrote:

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


I decided I would instruct Byron in how to unsubscribe from our mailing
list, when I discovered *I don't know how.*

It seems with HyperKitty we no longer have an easily-accessible way to
unsubscribe from our mailing lists. How can this be done without
registering a Fedora account?

Previously the option to unsubscribe was front-and-center when clicking
the link at the bottom of each mail.


by sending the unscubscribe mail to the corerct address
just look at the list headers

List-Unsubscribe:
,




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Stop please

[Reindl Harald]

Am 08.01.2016 um 22:39 schrieb Paul W. Frields:

On Fri, Jan 08, 2016 at 03:00:13PM +0100, Reindl Harald wrote:


Am 08.01.2016 um 14:53 schrieb Mark Bidewell:

Unfortunately GMail's web interface does not seem to recognize those
headers :(.  So a fair number of uses will have issues.


what is the purpose of breaking DMARC by add a list-footer pointing to a
site with no unsubscribe-information

why can't the list-footer contain that information at all or just be removed
when it has no real use besides breaking DMARC/DKIM and get quoted by
careless people making read posts harder?

FIX THAT HEADERS IN GENERAL - THE "--"-line needs to be "-- " for MUA's
recognize it as signature and don't quote it all the time


Did you file this bug upstream?


not sure if the list-footer is a upstream thing

for this reply it was not necessary to strip the footer because before 
was your signature with a correct "-- " containg a trailing space at the 
end of the line




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Stop please

[Reindl Harald]

Am 08.01.2016 um 14:53 schrieb Mark Bidewell:

Unfortunately GMail's web interface does not seem to recognize those
headers :(.  So a fair number of uses will have issues.


what is the purpose of breaking DMARC by add a list-footer pointing to a 
site with no unsubscribe-information


why can't the list-footer contain that information at all or just be 
removed when it has no real use besides breaking DMARC/DKIM and get 
quoted by careless people making read posts harder?


FIX THAT HEADERS IN GENERAL - THE "--"-line needs to be "-- " for MUA's 
recognize it as signature and don't quote it all the time


https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/


BTW thats a great tip on the headers, never know about them until today


every mailing list for decades has that headers



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: emacs-filesystem

[Reindl Harald]

Am 05.01.2016 um 11:17 schrieb Jan Synacek:

Michael Schwendt  writes:

2) A dependency on emacs-filesystem is primarily for packages, which store
files in those directories, but which do _not_ need Emacs to be installed.
Splitting off emacs- subpackages is not always the most wise/convenient
choice.


Any examples of such packages? I still can't imagine how storing emacs
specific stuff into emacs directories without requiring emacs could be
useful


any package dropping their snippets into 
/usr/share/bash-completion/completions/ - i doubt they all require 
"bash" and/or "bash-completion" but if it is used the completions are 
present




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Firefox build?

[Reindl Harald]

Am 28.12.2015 um 22:57 schrieb Bojan Smojver:

Release notes for FF 43.0.2 say that a security issue was fixed (MD5
signatures accepted within TLS 1.2 ServerKeyExchange in server
signature). Does this not affect Fedora builds?


what do you try to tell us with that question?

[harry@srv-rhsoft:~]$ rpm -q firefox
firefox-43.0-1.fc23.x86_64



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Specs using %define

[Reindl Harald]

Am 26.12.2015 um 22:45 schrieb Jason L Tibbitts III:

"MS" == Michael Schwendt  writes:


MS> %_bindir is not /bin

In Fedora there's not exactly much of a difference because of the
symlink.  But why conditionalize it on "%ifos linux" in any case?


there *is* a difference and hence of it i have a meta-package with 
Provides on any system because otherwise dependency repeatly can't be 
solved because "glibc" and "perl" where years after UsrMove not fixed 
and bugreports ignored


you get hit by it when perl/glibc are updated with the ame transaction 
while your own packages correctly using the macros for their Requires 
instead the old, hardcoded path


Provides:  %{_bindir}/perl
Provides:  %{_sbindir}/ldconfig

https://fedoraproject.org/wiki/Packaging:Guidelines#Effect_of_the_UsrMove_Fedora_Feature





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: lxqt

[Reindl Harald]

Am 24.12.2015 um 00:41 schrieb mastaiza:

This is a dead end that no one knows what to do


what about senseful quoting so that one could know what you are talking 
about? a subject "Re: lxqt" implies you are responding to something




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

grub2 password and docs

[Reindl Harald]

https://fedoraproject.org/wiki/GRUB_2#Setting_a_password_for_interactive_edit_mode
_

If you wish to password-protect GRUB2's interactive edit mode but you do 
not want to require users to enter a password to do a plain, simple, 
ordinary boot, create /etc/grub.d/01_users with the following lines:


cat << EOF
set superusers="root"
export superusers
password root secret
EOF
_

and then you find such a file there pointing to some "user.cfg" where 
nobody knows what \${prefix} is and how that is supposed to work - 
honestly the whole grub2 config stuff is cryptical crap while "More 
details can be found at Ubuntu Help: GRUB2 Passwords" even makes it more 
confusing


[root@testserver:~]$ cat /etc/grub.d/01_users
#!/bin/sh -e
cat << EOF
if [ -f \${prefix}/user.cfg ]; then
  source \${prefix}/user.cfg
  if [ -n "\${GRUB2_PASSWORD}" ]; then
set superusers="root"
export superusers
password_pbkdf2 root \${GRUB2_PASSWORD}
  fi
fi
EOF



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: grub2 password and docs

[Reindl Harald]

besides that the wiki is completly outdated "grub2-setpassword" only 
works on english machines 
https://bugzilla.redhat.com/show_bug.cgi?id=1292830


if /etc/grub.d/01_users would containa comment that 
"/boot/grub2/user.cfg" (who knows prefix just staring at the source of 
that file) just needs the hash output of "grub2-mkpasswd-pbkdf2" in the 
variable "GRUB2_PASSWORD" it would be so more helpful


[root@testserver:/etc/grub.d]$ grub2-setpassword
Enter password:
Confirm password:

[root@testserver:/etc/grub.d]$ locate user.cfg
/boot/grub2/user.cfg

[root@testserver:/etc/grub.d]$ cat /boot/grub2/user.cfg
GRUB2_PASSWORD=Passwort eingeben:
Passwort erneut eingeben:
PBKDF2-Prüfsumme Ihres Passworts ist 
grub.pbkdf2.sha512.1.094C7CFED3F6F9D9854C821E48C6D2909C720B806BF69303D5782EA31790AF2ACD89ED73DA4A53C1B94D7E37EC240AAEEA85E779E1C88DE0ECA899747479F130.C7CEB0D35AF519B3C616871AF2BE9C02B151EBFA57162192DF45DA39FF80F871E1D1D87FCFD7C33016412BA835AEA8FECCFA44431C8EA0B43150F62FE5BBB0EE


Am 18.12.2015 um 13:16 schrieb Reindl Harald:

https://fedoraproject.org/wiki/GRUB_2#Setting_a_password_for_interactive_edit_mode

_

If you wish to password-protect GRUB2's interactive edit mode but you do
not want to require users to enter a password to do a plain, simple,
ordinary boot, create /etc/grub.d/01_users with the following lines:

cat << EOF
set superusers="root"
export superusers
password root secret
EOF
_

and then you find such a file there pointing to some "user.cfg" where
nobody knows what \${prefix} is and how that is supposed to work -
honestly the whole grub2 config stuff is cryptical crap while "More
details can be found at Ubuntu Help: GRUB2 Passwords" even makes it more
confusing

[root@testserver:~]$ cat /etc/grub.d/01_users
#!/bin/sh -e
cat << EOF
if [ -f \${prefix}/user.cfg ]; then
   source \${prefix}/user.cfg
   if [ -n "\${GRUB2_PASSWORD}" ]; then
 set superusers="root"
 export superusers
 password_pbkdf2 root \${GRUB2_PASSWORD}
   fi
fi
EOF




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Reindl Harald]

Am 18.12.2015 um 15:39 schrieb Neil Horman:

On Thu, Dec 17, 2015 at 10:18:10PM +0100, Reindl Harald wrote:

What I hear you saying is that on a system that has nothing better to do, the
primary monitoring process wakes up periodically to check on various system
aspects (cron jobs, journal rotates, etc).  That sounds like working as designed
to me, not a reason to throw the proverbial baby out with the bath water.  That
seems like a reason to do some tuning.


it is wasting ressources in a container running only one process - period -
what is there to discuss - in any serious setup there shou,ld be nothing
installed which is not *really* needed


You're making two assumptions here:
1) That there is only one process
2) That systemd (or a component thereof) isn't needed

While you're use case is certainly valid, it isn't the only use case by a long
shot.  And if the goal for your use case is to minimize the footprint of a
container, you can already do that (as I've pointed out previously)


i don't make *any* assumptions

since kernel-core pull systemd anyways there is not much for discussion, 
by default systemd is there - so everybody is happy


the only difference is *where you know* you don't need it you are *able* 
to remove it




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Reindl Harald]

Am 18.12.2015 um 15:44 schrieb Neil Horman:

On Fri, Dec 18, 2015 at 01:27:33AM +, Zbigniew Jędrzejewski-Szmek wrote:

For some packages "reduced capacity" because of lack of systemd.rpm
means "doesn't even get started as expected" or "crashes on
start with permission errors" or "cannot write logs" or similar.
Like Lennart and Neil said, utilities provided by systemd.rpm are the
basis which allows many things to "just work". This is so obvious
that it is assumed implicitly in this disussion, and it's hardly
"personal use cases".


I concur, this really seems like were forsaking full OS functionality to support
a specific container use case, which is wrong.  And the argument that its ok
because the kernel will pull in systemd, while currently accurate seems like bad
practice, as philisophically rpms always specify all their requires instead of
assuming some other package will do it for them


no idea what you are talking about

following "as philisophically rpms always specify all their requires" 
than wahtever package has to have a "Requires: systemd" when it requires 
systemd and since that is not happening they all rely anyways that 
something else does it


so following your logic the change should be done in case there is no 
kernel installed and the packages in the container don't need systemd to 
have the ability to remove it





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: grub2 password and docs

[Reindl Harald]

Am 18.12.2015 um 20:30 schrieb Andrew Lutomirski:

On Fri, Dec 18, 2015 at 5:05 AM, Reindl Harald <h.rei...@thelounge.net> wrote:


besides that the wiki is completly outdated "grub2-setpassword" only works on 
english machines https://bugzilla.redhat.com/show_bug.cgi?id=1292830

if /etc/grub.d/01_users would containa comment that "/boot/grub2/user.cfg" (who knows prefix just 
staring at the source of that file) just needs the hash output of "grub2-mkpasswd-pbkdf2" in the 
variable "GRUB2_PASSWORD" it would be so more helpful



/etc/grub.d is consumed by grub2-mkconfig.  Since Fedora doesn't use
grub2-mkconfig after installation, basically every GRUB 2
configuration reference that has upstream GRUB 2 in mind doesn't
actually work on Fedora.

Perhaps Fedora should consider switching to using grub2-mkconfig
during normal use... :)


we had that discussion and it has *nothing to do* with 
/etc/grub.d/01_users don't contain a useful hint and a outdated wiki 
(not talking about the bug with LANG var)


"grub2-setpassword" is enough (after "LANG=C")



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Reindl Harald]

Am 18.12.2015 um 16:36 schrieb g...@cfware.com:

I have no experience with containers so forgive me if I'm missing something.  
Why couldn't you just have a 'microinit.rpm' in a separate dnf repo, put 
'Obsoletes: systemd' into that package?  This way people who are building 
hundreds of containers that do not require systemd can use the repo containing 
microinit and it will take the place of systemd.  RPM macro's could be provided 
by the microinit rpm, so it would provide reasonable replacements for 
%systemd_requires, %systemd_post, etc.  I think this could solve your concern 
with minimum (no) impact to bare metal installs.


because in that case a dependency of a package which really requires 
systemd would no longer work and it's only a dirty hack


"minimum (no) impact to bare metal installs" - how much bare metal 
installs have you seen where kernel-core is not present?




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Reindl Harald]

Am 17.12.2015 um 16:57 schrieb Lennart Poettering:

On Thu, 17.12.15 10:50, Matthew Miller (mat...@fedoraproject.org) wrote:


On Thu, Dec 17, 2015 at 04:40:16PM +0100, Lennart Poettering wrote:

Nope, that's not the point to make. We ship tons of stuff you don't
always need, but why is this stuff that matters? Is it *that* large?


"Ship" and "require in the most minimal application-only install case"
are different. And "eh, it's not that large" is the approach that's
lead us to having a collective minimal set that is undeniably unwieldy.
If, instead, every package at the base level would take modularity as a
baseline principle, we'd be in a lot better and more flexible state.


Does it have such heavy otherwise unneeded deps?


In some cases, yes. In others, it's deps that don't seem individually
heavy but they add up.


I am not sure I can read this any other way than "Nope, I won't be
specific with numbers and stuff, I just have the 'feeling' that
systemd is large and has huge deps"


read it they way: *anything* which is *not missed* when it's not 
installed should not be installed - period - there is nothing to dicuss 
about




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Reindl Harald]

Am 17.12.2015 um 16:54 schrieb Lennart Poettering:

On Thu, 17.12.15 10:44, Colin Walters (walt...@verbum.org) wrote:

What is cleaning up /tmp
for those things?


You bind mount the container's /tmp to a host /tmp/container-$uuid
for example.


Well, and what sets up all the rest listed in tmpfiles snippets?


well, you missed the topic is about *tiny* containers for single 
applications - not everything has tmpfiles snippets



If you want to replace systemd functionality with Docker
functionality, then that's fine, but I think you better make sure you
actually have replacement functionally around. Because otherwise you
just give up on platform design


no, you missed the point: not every systemd functionality is needed for 
all usecases (not that i run containers because i prefer full 
virtualization) but if i would run some hundret containers with a single 
application running systemd in each of them would be waste of ressources




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Reindl Harald]

Am 17.12.2015 um 17:03 schrieb Reindl Harald:



Am 17.12.2015 um 16:57 schrieb Lennart Poettering:

On Thu, 17.12.15 10:50, Matthew Miller (mat...@fedoraproject.org) wrote:


On Thu, Dec 17, 2015 at 04:40:16PM +0100, Lennart Poettering wrote:

Nope, that's not the point to make. We ship tons of stuff you don't
always need, but why is this stuff that matters? Is it *that* large?


"Ship" and "require in the most minimal application-only install case"
are different. And "eh, it's not that large" is the approach that's
lead us to having a collective minimal set that is undeniably unwieldy.
If, instead, every package at the base level would take modularity as a
baseline principle, we'd be in a lot better and more flexible state.


Does it have such heavy otherwise unneeded deps?


In some cases, yes. In others, it's deps that don't seem individually
heavy but they add up.


I am not sure I can read this any other way than "Nope, I won't be
specific with numbers and stuff, I just have the 'feeling' that
systemd is large and has huge deps"


read it they way: *anything* which is *not missed* when it's not
installed should not be installed - period - there is nothing to dicuss
about


OK, you want numbers

full featured VM running authoritative DNS for hundrets
of zones while bind and rsyslog would be enough
__

whole operating system: 795 MB

systemd: 24 MB
systemd-libs: 1.1 MB
__

(100 * 25.1) / 795 = 3,16%

sorry, 25 MB in each container *is bloat* and you pull deps
like dbus and it's dep-chain not needed to run a single process
which has no business for IPC since there is no other process

not so long ago systemd unconditionally pulled "libmicrohttpd"
as dependency - most deps have chains and when you get rid of
one package you can get rid of their deps too

yes, many would now argue "but that's not much overhead", but
that overhead on 100, 200, 500 containers makes a total sum





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Reindl Harald]

Am 17.12.2015 um 21:47 schrieb Craig Garner:

I usually don't say anything and just read...it's not really my place.
I just like to keep up with things going on.  But, by the time you
finish worrying about all the overhead and things get finalized, there's
going to be so damn much RAM and processing power no one will care.
Kind of like developing one white blood cell to defend your entire body.


this is pure nonsense and the attitude "going to be so damn much RAM and 
processing power no one will care" is the reason that machines these 
days are not nearby as fast as they could and should be compared with 
machines 10 years ago - brainless ressource wasting


when you have real production load and a ton of virtual machines and 
containers running on the same host and every one of them is wasting 
ressources the summary of all the overhead is something you care or 
should care about




On Thu, Dec 17, 2015 at 3:39 PM, Colin Walters > wrote:

On Thu, Dec 17, 2015, at 01:19 PM, Neil Horman wrote:
>
> In either case, you're going to wind up butchering a fair amount of what 
the rpm
> is going to be doing anyway.  If its so important to minimize that 
storage, rpm
> dependencies shouldn't really be a big deal, because you know you're 
going to
> have to either do some FS surgery anyway.

What I'm actually arguing long term is to rearchitect the model of
the subset
of Fedora that is for server containers to support this - something
like a "just the binaries"
data blob, and then *optionally* turn that intermediate into an RPM
that would
have a systemd unit file.  It could really be an RPM, just without
the %post
scripts relating to systemd and the unit files.

In practice though, it's not a big deal as long as shared libraries
don't
end up pulling in systemd or other components.  And for software that's
container-only, the build process (Dockerfile or something better in the
future) for containers just won't require it.

> Yes, its more than one process.  I think thats the better tradeoff though.

What you're arguing is that *build* convenience for our current
architecture
outweighs the *runtime* cost.  That doesn't make sense long term -
they're
different problems.




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Reindl Harald]

Am 17.12.2015 um 19:43 schrieb Neil Horman:

On Thu, Dec 17, 2015 at 05:18:21PM +0100, Reindl Harald wrote:

OK, you want numbers

full featured VM running authoritative DNS for hundrets
of zones while bind and rsyslog would be enough
__

whole operating system: 795 MB

systemd: 24 MB
systemd-libs: 1.1 MB
__

(100 * 25.1) / 795 = 3,16%

sorry, 25 MB in each container *is bloat* and you pull deps

So dont put it in each container, put it in a parent container that can be
inherited via btrfs subvolumes or unionfs.  The only reason this seems like a
significant number is because you seem to be insisting that it has to be copied
into each container. If you share it (as you should), the space requirements
become negligible very quickly at scales of hundreds of containers


bla - i have also zero understanding for 25 MB in every full 
virtualization VM and when you look at the sizes systemd grows with each 
fedora release




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Reindl Harald]

Am 17.12.2015 um 22:00 schrieb Neil Horman:

On Thu, Dec 17, 2015 at 03:39:17PM -0500, Colin Walters wrote:

What you're arguing is that *build* convenience for our current architecture
outweighs the *runtime* cost.  That doesn't make sense long term - they're
different problems.

What runtime cost are you referring to here?  The cost of running systemd in a
container?  Its miniscule, given that its only job is to start a handful of
units and get out of the way


that's not true

on virtual machines with no load all day long PID1 is often found as 
number 1 in htop sorted by CPU usage - multiply that with 500 and you 
have a *useless* and well noticeable load on the host




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Reindl Harald]

Am 17.12.2015 um 22:11 schrieb Neil Horman:

On Thu, Dec 17, 2015 at 10:04:48PM +0100, Reindl Harald wrote:

Am 17.12.2015 um 22:00 schrieb Neil Horman:

On Thu, Dec 17, 2015 at 03:39:17PM -0500, Colin Walters wrote:

What you're arguing is that *build* convenience for our current architecture
outweighs the *runtime* cost.  That doesn't make sense long term - they're
different problems.

What runtime cost are you referring to here?  The cost of running systemd in a
container?  Its miniscule, given that its only job is to start a handful of
units and get out of the way


that's not true

on virtual machines with no load all day long PID1 is often found as number
1 in htop sorted by CPU usage - multiply that with 500 and you have a
*useless* and well noticeable load on the host


What I hear you saying is that on a system that has nothing better to do, the
primary monitoring process wakes up periodically to check on various system
aspects (cron jobs, journal rotates, etc).  That sounds like working as designed
to me, not a reason to throw the proverbial baby out with the bath water.  That
seems like a reason to do some tuning.


it is wasting ressources in a container running only one process - 
period - what is there to discuss - in any serious setup there shou,ld 
be nothing installed which is not *really* needed




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Easier %config management?

[Reindl Harald]

Am 14.12.2015 um 17:01 schrieb Christopher:

On Sun, Dec 13, 2015 at 3:39 PM Reindl Harald <h.rei...@thelounge.net
For me, I'd want the up-to-date one from the current version of the
installed packages, not the initial state... just the up-to-date state
as determined by the package maintainer. My main interest is finding
what the user changed, to make it different from the packager's defaults.

when the system was installed versus current state?
worthless - most of my Fedora setups are from 2008

the current and the previous version?
well, you need to handle cases where a config file is unchanged but the
package is updated, that's the majority of all updates

For me, I just want to know what the user changed


what you propose can't work for that because you only compare the 
*current users* version with the *current package* version


that is a naive approach

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


the same happens to anything which has large changes over time

the moment when config formats are changing is the one where it starts 
to become interesting and at that moment is completly wortless to 
compare different generations of a config file without the full history


what you *really* would need to compare at *that moment* is your changes 
years ago based on the dist-version of the config file at the same moment


that's nothing you can or should try to cover with rpm - try to solve 
this with 1 or 2 limited copies would fail after dist-upgrades as i have 
already said


compare two versions is worthless, you need at least three to *get a 
context*


* previous dist version - CAUTION
* your current version
* now to install/installed dist-version

which previous dist-version owul dbe helpful depends, the most 
interesting one is that from where user changes derived and to answer 
that question you need more data than one copy because form the first 
change on the *users version* will always differ, but from which distro 
state did that happen






signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Easier %config management?

[Reindl Harald]

Am 13.12.2015 um 21:50 schrieb Andrew Lutomirski:

On Dec 13, 2015 12:38 PM, "Reindl Harald" <h.rei...@thelounge.net
<mailto:h.rei...@thelounge.net>> wrote:
 >
 > Am 13.12.2015 um 21:22 schrieb Andrew Lutomirski:
 >>
 >> For the few cases that can't or won't comply, then having rpm
 >> (optionally?) make the originals available would be fantastic for
 >> system management
 >
 >
 > how many copies would you like to store in the rpm database and how
to access them in a useful manner

Exactly one, for the current installed version.


not terrible helpful


 > honestly:
 > that all violates the unix principles one tool for one task and there
are tools available for config file management many years, people
interested just need to use them, "etckeeper" is integrated in dnf/yum
and makes a versioned "snapshot" of /etc before and after updates are
applied

Since when is there a UNIX principle that, just because a mediocre
solution exists, a better solution shouldn't be added.


how can bloating the rpm-database in a very limited way be a better 
solution than having any changes below /etc versioned over years



In any case, most existing tools really struggle with "what has changed
on my configuration relative to what I'd have if I reinstalled?"


how is rpm here a solution?

how should it know which version is "if I reinstalled" after several 
dist-upgrades - keep the very first version of a config file makes no 
sense - how would a httpd.conf from 2008 help on a Fedora 23 with 
httpd-2.4 and the same for most other package over the time?




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Easier %config management?

[Reindl Harald]

Am 13.12.2015 um 05:58 schrieb Christopher:

rpm could track more than hashes of config files, and instead track the
full file. This could be optional, as it uses more disk space, but disk
space is cheap these days, and config files are relatively small. This
would avoid having to re-download the rpm, and would make it easier to
see what has been modified on their system. So, some users may find that
a worthwhile trade-off


first:  disk space is *not* cheap these days *
second: etckeeper exists
third:  no need to re-invent the wheel

99% of all users don't care and the yone who cares using a VCS for /etc 
like "etckeeper" while i never ever would use that directly on 
production servers but on a admin-server pull from the infrastrcuture 
and fire etckepper there - works like a charme for many year


*
disk space maybe cheap for some fire-and-forget machines, but not on 
enterprise storage hosting hundrets of instances




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Easier %config management?

[Reindl Harald]

Am 13.12.2015 um 21:22 schrieb Andrew Lutomirski:

For the few cases that can't or won't comply, then having rpm
(optionally?) make the originals available would be fantastic for
system management


how many copies would you like to store in the rpm database and how to 
access them in a useful manner


define "originals"

when the system was installed versus current state?
worthless - most of my Fedora setups are from 2008

the current and the previous version?
well, you need to handle cases where a config file is unchanged but the 
package is updated, that's the majority of all updates


honestly:
that all violates the unix principles one tool for one task and there 
are tools available for config file management many years, people 
interested just need to use them, "etckeeper" is integrated in dnf/yum 
and makes a versioned "snapshot" of /etc before and after updates are 
applied




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 11.12.2015 um 15:09 schrieb Paul Wouters:

On 12/09/2015 06:02 PM, Oron Peled wrote:


Why don't we plan this feature in two stages:
  * Fedora 24: turn it on by default, but *keep using results* from bad DNS 
servers,
just issue a user-visible warning, possibly with a link to a page with 
friendly
explanation and suggestions for further action.


DNS lookups don't have users like web browsers


and there is *no* safe and clean way to solve that

since it's the DNS server it *could* return in such case a dedicated IP 
to a site which accepts every host header and explains what have 
happened - BUT that won't work with HTTPS sites, they wuld end just in 
another warning AND NO don't come with the idea install a Fedora 
certificate like Dell did it short ago


the problem here is that the browser would send it's cookies from 
previous visits there so it's not possible for security/privacy reasons 
and since DNS don't cover ports there can also not be a tiny process on 
the local machine with a embedded webserver easily, the user could have 
run it's own webserver which must not be replaced




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: %post RPM scriptlets and dependencies

[Reindl Harald]

Am 10.12.2015 um 12:53 schrieb Rex Dieter:

Florian Weimer wrote:


When a %post scriptlet runs, is it guaranteed that the Requires:
dependencies have been unpacked?  I understand that for cycle-breaking
purposes, it may not be true that the scriptlets for dependencies have
run.  But are the files already there?


I think the answer in general is no, you cannot be guaranteed that Requires:
get installed before %post runs.  That's one reason why Requires(post)
exists


sounds terrible

what's with the "Require" of a "Requires(post)" to guarantee that the 
"Requires(post)" *really* work sucessful? sounds fragile




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Direct messages

[Reindl Harald]

Am 09.12.2015 um 10:45 schrieb Dominik 'Rathann' Mierzejewski:

On Wednesday, 09 December 2015 at 10:37, Tom Hughes wrote:

On 09/12/15 09:34, Dmitrij S. Kryzhevich wrote:


If your username is krege you got at least three e-mail on 2015-11-26,
-15 and -10 to krege fedoraproject org, therefore I suggest that you
check your Spam folder/e-mail configuration.



And I found those letters. Sorry, it was... very nontrivial.
Heades (@ sign was manually edited):

From: opensource-at-till.name
To: devel-at-lists.fedoraproject.org  // ! (my note)
...
Delivered-To: krege-at-fedoraproject.org  // and here we are

Sure it was auto-moved into devel@ folder. Is it OK to use such a "To"
field?


Well it's a report to the list, bcced to you as an affected person
presumably.

If you want to filter list mails then List-Id is a much better thing to
filter on than the To header. That way a direct copy to you won't trigger
the filter.


I was bitten by this two times already. Once, when fedora migrated all
mailing list names from fedora-foo to just foo and recently, when the
lists were migrated to hyperkitty. Here's my current procmailrc recipe
for unmangling the e-mails to fedora mailing lists and sorting them
to fedora-foo maildirs:


hence use the envelope-sender
Return-Path: devel-boun...@lists.fedoraproject.org


:0
* ^List-Id:.*<\/[^\.]+\.lists\.fedoraproject\.org
{
 LISTNAME = fedora-`echo $MATCH | sed -e 's/[\/]/_/g' -e 
's/.lists.fedoraproject.org//'`

 :0:
 $MAILDIR/.$LISTNAME/
}




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 08.12.2015 um 10:25 schrieb Petr Spacek:

On 8.12.2015 09:41, Gerd Hoffmann wrote:

   Hi,


Start moving away from
split DNS because that's going to be very hard to support.


Seriously?  How do you suggest to handle DNS for my 192.168.2.0/24 home
network then?  Making the forward zone for home.kraxel.org public would
at least work, although I fail to see the point in having public dns
records for private networks.  Registering the reverse zone is never
ever going to work though ...


For the record, this is an invalid example.

Special-use domain names are listed in IANA registry
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml


what is there invalid?

* rhsoft.net is my public zone
* rhsoft.net is also my internal DNS zone
* there is no point calling my smart-tv "tv.example.com"
  instead "tv.rhsoft.net"
* there is also no point to add a 192.168.x.x record in public DNS
* there is also no point calling my devices something.test
* .local shouldn't be used (look in the samba list-archives)

not that i am affected by any network changes Fedora decides since my 
local DNS server will always be a full featured BIND forwarding any 
non-lan zones over VPN to the comapany nameservers where i also control 
the internal and external DNS views, but there are *millions* of valid 
use-cases for split-DNS





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi front page after login

[Reindl Harald]

Am 07.12.2015 um 14:05 schrieb Michael Schwendt:

On Mon, 7 Dec 2015 11:53:26 +0100, Vít Ondruch wrote:


You can find all your updates under the 'profile' tab. You could even
set a bookmark to this page.



I can hardly see what has my "profile" in common with my updates. They
should be shown on the  welcome screen.


It's not the only web site where a person's public activity can be viewed
on the person's public profile page. That way you can look for a person's
updates, for example. I could understand extra features like that.

However, that's still no reason for the login welcome page to not list the
person's own updates or to explicitly highlight those that wait for action.
To say that "other folks find the overall status more interesting" is a poor
excuse for the page not being customisable


you clearly underestimate the work making a web-application 
customizeable in a way making everybody happy!


why can't you not just set a bookmark in the time you write 5 mails?

i could argue the same way why i have to make a dozen of selections in 
the RH bugtracker to submit a Fedora bug or just klick on the 
bookmark-toolbar with 
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 07.12.2015 um 15:56 schrieb Pádraig Brady:

On 01/12/15 15:59, Randy Barlow wrote:

This sounds overall pretty neat to me! One detail came to my mind: how
would this interact with VPN DNS servers? In my experience with VPNs,
it's common for them to provide a DNS server that allows internal host
resolution to work. Would this local resolver be notified by NM of a new
VPN connection so that it knows to use the VPN-provided DNS server for
hosts on that particular domain, rather than the usual external records
for that same domain?


That split DNS setup has been working well for me since Fedora 21,
which I enabled using:

   dnf install crudini
   crudini --set /etc/NetworkManager/conf.d/99-split-dns.conf main dns dnsmasq

Details of that setting are in man NetworkManager.conf
Not sending general DNS queries over the VPN
improves speed and avoids stalls when the VPN drops


depends on the VPN - if my company VPN drops i have to take a taxi 
anyways because it only drops when houston has a problem


given we have some hundret domains the whole point of the VPN is working 
from home the same way as if i would be in the office and make *anything 
which is possible* through the DHE-4096 connection and avoid as much as 
possible network contact bypassing the tunnel




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 07.12.2015 um 20:48 schrieb Paul Wouters:

Move your own domains within one of your real legitimate domains, and
you have the freedom to do whatever you want. Start moving away from
split DNS because that's going to be very hard to support.


that's simply not possible for every environment

cases where your company stuff is behind a VPN and your normal internet 
connection and DNS resolution for anything else is using your ISP's 
nameserver are quite common


frankly when you sit in a customer LAN provisioning it's own DNS and 
internal views from where you at the same time have a VPN tunnel to your 
own company network there is no way to avoid "split DNS"


not that i use such setups but that's real world usage



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 07.12.2015 um 21:40 schrieb Paul Wouters:

On Mon, 7 Dec 2015, Florian Weimer wrote:


Clearly, fedora cannot be changed to hijack a real domain, so
Fritzbox better
solve this quickly with an update, even if no one actually will
update their
router :(


Well, AVM could just register fritz.box and leave it unsigned, which
solves the problem for us.


If my fritz.box is 192.168.1.254 and yours is 192.168.1.1, what would
you want the AVM registered domain fritz.box to return as A record?

One of us will break regardless, unless the fritz box hijacks all port
53 to push it through its preprocessor its fake .box domain


* typically this devices act as DNS for the LAN
* fritz.box != *.box
* hence your or his IP don't matter



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: DNF could improve messages about package auto-removal

[Reindl Harald]

Am 06.12.2015 um 04:26 schrieb Kevin Kofler:

Mathieu Bridon wrote:

Note that packages installed by PackageKit are not marked as installed,
so dnf always thinks it can remove them.


This makes "autoremove" completely unsuitable for end users and totally
inappropriate as a default (and the only suggestion we can give them is to
NEVER use dnf, only PackageKit or yum-deprecated)


the bug here is "PackageKit" which in the meantime luckily can be 
removed entirely again on F23 while with F22/F23 it was a dependency for 
KDE packages






signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: yum: Critical path update in testing for 4 months?

[Reindl Harald]

Am 06.12.2015 um 15:30 schrieb Richard Shaw:

Usually I don't dig too deep but I saw a "critical path" update for yum
on F22 (which should be using dnf anyway).

So why is a critical path update with +10 karma still in testing?

(I know how, there's no auto push to stable based on karma for this update)


that's the reason that it did not happen automatically

but what is the reason for maintainers building updates without the 
intention to push them?


bodhi should punish maintaines with daily mails when a package has 
enough karma or has reached the time to get pushed even without karma so 
that the maintainer has a good reason for push it or decide to delete it 
(with a very good reason)




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: yum: Critical path update in testing for 4 months?

[Reindl Harald]

Am 06.12.2015 um 19:52 schrieb Michael Schwendt:

Currently I have two security fixes, which are two months old. Nobody
does the needed testing. The karma isn't reached. Nobody ensures that
they enter the stable updates repo even with 0 karma. Meanwhile, F21
has reached end-of-life without anyone making sure to do a last push
of security fixes for it. If I had not released any fixes, nobody would
have reminded me. In other cases, there have been CVE tickets in bugzilla
filed by the security team from Red Hat with nobody working on fixes for
Fedora, not even sending reminders. We need more thinking humans to make
the right decisions. Look at the age of updates in the updates-testing
reports! This is crap 2.0


that may all be true - BUT i have zero understanding for cases where i 
make a distr-upgrade, start as usually "fedora-easy-karma" and find a 
ton of "this package could be pushed to stable if the maintainer wishes" 
candidates


and for "There are maintainers, who dislike a lot of things related to 
the release processes. They consider bodhi a pain to use. They would 
prefer doing things differently, with less work, and more like 
fire'n'forget as how they do it within Rawhide" than frankly what's the 
point of prepare a update when one don't care about it? it's not a 
matter of like or disklike - it's a point of responsibility




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: yum: Critical path update in testing for 4 months?

[Reindl Harald]

Am 06.12.2015 um 21:20 schrieb Michael Schwendt:

And as you are not a package maintainer at Fedora, it could be that you
underestimate the amount of burden/bureaucracy that's considered
unnecessary by many packagers


explain me the burden/bureaucracy in the countless cases where 
"fedora-easy-karma" shows the status "this update has reached... and can 
be pushed to stable when the maintainer wishes" other then just press 
the button




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi front page after login

[Reindl Harald]

Am 06.12.2015 um 20:06 schrieb Michael Schwendt:

When I log in at  https://bodhi.fedoraproject.org/  the new web ui
greets me with a huge wall of uninteresting statistics, such as

  * the activity of other update submitters,
  * this week's top testers
  * latest updates in need of testing

Why doesn't it greet me with my own updates anymore?

Some have been four months old and haven't received any testing.
Perhaps that also means I should retire those packages as well,
if there is not even a single user to give feedback on them


"if there is not even a single user to give feedback on them" is a jerk 
reaction - the majority of users don't have updates-testing enabled and 
just wait for stable updates


taht said from someone who is most of the time in the top 5 testers as 
long nobody breaks fedora-easy-karma




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 06.12.2015 um 21:06 schrieb Chris Murphy:

On Sun, Dec 6, 2015 at 8:05 AM, drago01  wrote:
Hypothetically on BIOS systems, a GRUB core.img [1] could become stale
over time, and an upgraded grub-mkconfig could introduce an
incompatible format change, but that's really unlikely and wouldn't be
intentional.

This isn't possible on UEFI. Any update of grub2-efi means the
core.img is replaced with a generically built one (that's also signed
by a Fedora key for the purposes of supporting UEFI Secure Boot).


the world don't turn around UEFI


Until this is fixed grub2-mkconfig is dangerous and should not be used.


That's such an overstatement as to be wrong. Pretty much all other
distributions have been doing this for a long time to no ill effect.


he told you he was personally affected


[1] The code embedded into the MBR gap, or BIOSBoot partition; a.k.a.
GRUB legacy terminology was stage 2 bootloader. It's created and
embedded by the grub2-install command; which is unnecessary (and
arguably deprecated) on UEFI systems.


and you are going to change existing systems running for many years and 
surivived all dist-upgrades to UEFI *without* reinstall or lose /boot 
redundancy by RAID1? grub2-install needs to be manually done on all 4 
drives


frankly my current workstations where installed with F14 and RAID1 for 
/boot as well as RAID10 for anything else, they support UEFI but i gave 
up with Anaconda, now they happily run Fedora 23 with dist-upgrades and 
will as long some jerk decides to kill BIOS support or i die


the same applies to more than 30 production servers installed with 
Fedora 9 years ago and currentyl on F22 on top of VMware - fine, Vmware 
now supports UEFI too - but tell me *one valid* reason to change them!




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: yum: Critical path update in testing for 4 months?

[Reindl Harald]

Am 06.12.2015 um 22:29 schrieb Michael Schwendt:

What's needed is software developers and policy makers to agree that some
areas are problematic, and to agree on ideas and an agenda. To agree that
the karma system is flawed and things like testers ignoring past votes and
overriding another's -1 with their own +1 should not be possible


really?

i have seen more than once a -1 from somebody because *his* bug was not 
fixed by the update but others where - in that case *it is not* a 
regression and there is no point for -1


if i would get 1$ for every update which got a +1 from me while it did 
not fixed for me annyoing bugs *just because* they where *no regression* 
in *that* build i would be rich!




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: yum: Critical path update in testing for 4 months?

[Reindl Harald]

Am 06.12.2015 um 23:50 schrieb Michael Schwendt:

You expect packagers to review all their bodhi tickets everytime they
receive a nagmail from bodhi, and then to decide again whether to wait for
testers or whether to push manually without any prior feedback. That doesn't
scale for everyone. The list of active updates inside the web ui can
grow easily, too


yes, i expect this when i am able to follow all fedora and 7 other 
mailing-lists including bodhi-mails and give karma and review 100-400 
mail samples for bayes-training every day besides my daily jobs as the 
only sysadmin for more than 30 Fedora based servers, a few test-servers, 
4 fedora-based routers and get my *really* dayjob as software developer 
done at the same time


yes i expect that someone is able just read his mails and push a button 
on a list in a webinterface




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 06.12.2015 um 21:22 schrieb Chris Murphy:

So yeah it's possible, but it's also unintended. And the same problem
could happen whether grubby modifies grub.cfg or grub-mkconfig
replaces it


that's wrong because grubby *clones* the last recent entry with all it's 
parameters and don't touch other boot entrie snor the rest of the 
configuration




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 17:23 schrieb Andrew Lutomirski:


On Dec 2, 2015 8:15 AM, "Josh Boyer" > wrote:
 >
 > On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski > wrote:
 > > Since the old proposal to have the bootloader automatically enumerate
 > > boot options never went anywhere, can we do the next best thing?
 > >
 > > Specifically, these days grub2-mkconfig appears to produce output
 > > that's functionally identical to what grubby generates.  Can we switch
 > > new-kernel-pkg to just regenerate the grub2 config using
 > > grub2-mkconfig instead of using grubby?
 >
 > I don't think so.  Despite the similarity in name, grubby does more
 > than just deal with grub stuff.  Namely, it handles bootloaders that
 > aren't grub.  We're close to having all arches on grub2, but I believe
 > armv7hl won't ever get there and it's a primary arch.

Could we switch for grub2 architectures and keep using grubby for other
architectures?


no - there is a world without grub2
https://fedoraproject.org/wiki/Features/SyslinuxOption




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 21:31 schrieb Andrew Lutomirski:

On Wed, Dec 2, 2015 at 12:21 PM, Reindl Harald <h.rei...@thelounge.net> wrote:



Am 02.12.2015 um 21:16 schrieb Andrew Lutomirski:


On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer <jwbo...@fedoraproject.org>
wrote:


That's a matter of preference.  If I have a newer kernel version
installed that doesn't actually work, I want the older kernel I _just_
installed to be the default and top entry so my machine boots to
something I can use.  This happens often when people try rawhide -rcX
kernels to test something.

Fixing this might be better served by filing an RFE for grubby to
change the preference order.



Or file an RFE for grub2 to have an option to use the file timestamps
instead of the version for the sort order



breaking news: file timestamps of packages are independent of the install
time so this can't work - any attributes like timestamp, owner, permision
are part of the package for good reasons (rkhunter as example compares them
with the rpm database)


Can you please try to reduce your level of sarcasm on the list?


i try, but sometimes it's obviously needed


It's especially irritating when you're simultaneously sarcastic and
factually incorrect:


no, i am 100% correct in that context or why does my kernel have a 
timestamp from yesterday but was updated today?


[root@rawhide ~]# cat /var/log/dnf.rpm.log | grep kernel | grep 
4.4.0-0.rc3.git1.1

Dec 02 19:55:47 INFO Installed: kernel-core-4.4.0-0.rc3.git1.1.fc24.x86_64
Dec 02 19:55:47 INFO Installed: kernel-core-4.4.0-0.rc3.git1.1.fc24.x86_64

[root@rawhide ~]# ls -lha /boot/vmlinuz-4.4.0-0.rc3.git1.1.fc24.x86_64
-rwxr-xr-x 1 root root 6.4M 2015-12-01 17:34 
/boot/vmlinuz-4.4.0-0.rc3.git1.1.fc24.x86_64




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 20:35 schrieb Andrew Lutomirski:

On Wed, Dec 2, 2015 at 9:50 AM, Josh Boyer  wrote:

And you would do that via a single command how?  By wrapping it in an
architecture/bootloader agnostic wrapper.  Which is what grubby is.


But it's not.  grubby does things like adding kernels and removing
kernels.  grub2-mkconfig enumerates kernels and generates a config.


and if it has a bug you are lot with *all* entries borked


#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

That's grossly misleading.  It *was* automatically generated, but it
is certainly not automatically generated on an ongoing basis.  If I
change settings in /etc/default/grub, nothing happens.  If I actually
want to change boot options, I have to either manually edit every
instance (or somehow, magically, the correct subset of copies) in
/etc/grub2-efi.cfg, which is a real pain and easy to screw up


no - if you want them all identically just run grub2-mkconfig manually 
but don't expect that i am happy when something put's the same error 
into every entry


https://bugzilla.redhat.com/show_bug.cgi?id=840204 is probably the best 
example - with grubby you where able to add the needed option to the 
most recent entry and survived kernel updates


with grub2-mkconfig *every* single kernel update without edit the config 
before reboot meant go to your car and drive 300 miles to the remote 
machine or explain somebody how to get screen and keyboard on the 
headless machine and hand out the password




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 20:35 schrieb Andrew Lutomirski:

1. grubby puts the most recently-installed kernel on top.
grub2-mkconfig puts the highest version on top.  In the cases where
they differ, I'd argue that the latter is better


it's not better

it's pure crap when you have to downgrade because the higher kernel just 
don't work proper on your machine - there is one and only single reason 
why the most recently is lower - a downgrade by intention




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 21:16 schrieb Andrew Lutomirski:

On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer  wrote:

That's a matter of preference.  If I have a newer kernel version
installed that doesn't actually work, I want the older kernel I _just_
installed to be the default and top entry so my machine boots to
something I can use.  This happens often when people try rawhide -rcX
kernels to test something.

Fixing this might be better served by filing an RFE for grubby to
change the preference order.


Or file an RFE for grub2 to have an option to use the file timestamps
instead of the version for the sort order


breaking news: file timestamps of packages are independent of the 
install time so this can't work - any attributes like timestamp, owner, 
permision are part of the package for good reasons (rkhunter as example 
compares them with the rpm database)




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 21:46 schrieb Andrew Lutomirski:

The fact that you assert your absolute correctness on a frequent basis
even when you're not correct makes me, and probably other people,
likely to discount everything you say even in the cases when you are
correct.  If you want your opinion to be helpful, please reconsider
how you write your emails.


the problem with that thread is that you discount anything because you 
refuse trying to understand that it is a *very* bad idea to touch *all* 
boot entries after a kernel install



Anyway, I filed an RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1287854


and i answered why it is a bad idea there

"regenerating config instead of incrementally" leads in change 
*intentional* differences of options when someone tries to debug kernel 
problems and much more worse: a bug there would render *all* boot 
options unbootable instead only the last installed one


frankly one can even raise "installonly_limit" by intention and have the 
same kernel version with *multiple* options - that all would be erased 
by try out if a newer build fixes the problem


now you can say: that's not a problem for the ordinary user
i say: the ordianry user don't touch kernel options at all



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

upgrade path

[Reindl Harald]

why in the world can the "offical" upgrade tools not handle things which 
are with "yum --releasever=XX distro-sync" or now "dnf --releasever=XX 
distro-sync" are a nobrainer for many years just because such packages 
are get *downgraded* implicitly and so the "release"-tag don't matter at 
all?



 libxml2-2.9.3-2.fc23

  Update ID: FEDORA-2015-48362b03d1
Release: Fedora 23
 Status: pending
   Type: unapproved critpath bugfix
  Karma: 0/3
Request: testing
   Bugs: https://bugzilla.redhat.com/1287262 - dnf system upgrade 
fails due to libxml2 dependency
  Notes: This update fixes a packaging issue that caused F22 to F23 
upgrades to fail with a dependency solving error




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org