Re: Plasmashell: Alt+F2 not working

[John Florian]

On 8/18/21 12:37 PM, Sergio Belkin wrote:
El mié, 18 ago 2021 a las 12:24, Iñaki Ucar (>) escribió:


On Wed, 18 Aug 2021 at 14:32, Sergio Belkin mailto:seb...@gmail.com>> wrote:
>
> Hi folks,
>
> Since a few days ago, the keyboard shortcut Alt+F2 for opening
"run command" box is not working.
>
> journalctl shows complaints as follows:
>
> plasmashell[231184]:  Could not open library 'libkdeinit5_'.
> plasmashell[231184]:  Cannot load library libkdeinit5_:
(libkdeinit5_: cannot open shared object file: No such file or
directory)
>
> Any ideas?

Same issue here. Go to System Settings > Workspace > Shortcuts. I had
two entries for KRunner there for some reason: one showing the icon
and a blank one. I removed the latter and configured the shortcuts in
the other, and now it works fine again.

-- 
Iñaki Úcar

___
devel mailing list -- devel@lists.fedoraproject.org

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

Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure



Thanks Iñaki, that made the trick, indeed some of the last updates 
causes this  issues

--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org 



Mine has been broken for some time as well.  This inspired me to try and 
fix it.  I had the same duplication, including the blank icon. Removing 
that did not work for me, however.  I noticed that I have a "Run 
Command" entry and a "KRunner" entry.  The Alt+F2 and Alt+Space bindings 
were on "Run Command", so out of curiosity I tried moving them to 
"KRunner" instead.  That *did* work for me.  I don't know if these are 
different names for the same thing or what's going on exactly, but I'm 
happy to have the basic feature back.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bodhi login error

[John Florian]

On 8/17/21 2:41 PM, Kevin Fenzi wrote:

On Tue, Aug 17, 2021 at 09:59:38AM -0400, John Florian wrote:

I'm trying to report success on
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec4a4b2634 but cannot
login.  When I attempt to do so, the page shows:

500 Internal Server Error
Could not convert return value of the view callable function
pyramid_fas_openid.view.verify_openid into a response object. The value
returned was None. You may have forgotten to return a value from the view
callable.

You seem to be entering your @fedoraproject.org alias/address there?

Instead just use your username...

kevin


Thanks Kevin!  That was exactly the problem.



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

Bodhi login error

[John Florian]

I'm trying to report success on 
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec4a4b2634 but 
cannot login.  When I attempt to do so, the page shows:


500 Internal Server Error
Could not convert return value of the view callable function 
pyramid_fas_openid.view.verify_openid into a response object. The value 
returned was None. You may have forgotten to return a value from the 
view callable.

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

Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)

[John Florian]

On 5/13/21 9:45 AM, Simo Sorce wrote:
> On Wed, 2021-05-12 at 16:35 -0400, Ben Cotton wrote:
>> == Benefit to Fedora ==
>> This change makes the Fedora systems installed by Anaconda more secure
>> from remote password guessing attacks targeting the root account as it
>> would no longer be possible to configure a system that allows root to
>> login via SSH with password.
>>
>> A smaller benefit is making the root password configuration screen
>> less confusing by removing the "Allow SSH root login with password" &
>> Anaconda code cleanup related removing code related to setting up the
>> override in sshd.
> To be honest I object to this characterization.
>
> There is no added security given the default is not changed. This only
> removes a valid option that users that install images for testing
> locally on their computer use. It just makes it harder but does not
> change the security of Fedora one yota, as uses can still log in after
> install and re-enable root login with passwords, or use a kickstart
> file to do the same.
>
> If this is being done because maintaining the option for Anaconda
> developers then just say that. Otherwise do not do this change and let
> people that need it for convenience have it.
>
> Simo.
>
This will be a major PITA for me as well.  Most of my machines are
internal facing only and are VMs.  There are lots of ways to provision a
host; kickstarts being just one.  I made a commitment to using Puppet
instead because it enforces a setup thereafter, not just at install
time.  The same would be true with Ansible or any other of this ilk.  I
can't/won't have a local user account until Puppet is run because that's
all achieved with NFS, LDAP and Kerberos -- things I don't want to try
and achieve or replicate in a kickstart.  Sure, I could have a kickstart
install/start Puppet, but it's MUCH easier to check this one box than it
is to enter in a long URL where a kickstart can be reached.  In the end,
my SSH config will still be more hardened than what would be achieved by
removing this checkbox.

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

Re: Bacula 11.0.2-3 for Fedora 33?

[John Florian]

On 4/27/21 1:52 PM, Steven A. Falco wrote:
> On 4/27/21 5:14 AM, Paul Howarth wrote:
>> On Sun, 25 Apr 2021 11:17:49 -0400
>> "Steven A. Falco"  wrote:
>>> Are there any additional instructions on how to update the bacula
>>> database?
>>
>> Normally I would use /usr/libexec/bacula/update_mysql_tables but I
>> found in this case that it didn't work because it was trying to drop an
>> index from a table that didn't already exist (the index, not the
>> table).
>
> Thanks for the reply.  I turned out to be able to run:
>
> /usr/libexec/bacula/update_bacula_tables
>
> I'm using postgresql, and the script did manage to update the
> database.  And as you say, it took a long time.
>
> Then, I was getting failures from bacula that it couldn't insert into
> the File area, and I found that I additionally had to re-run:
>
> grant_bacula_privileges
>
> Once I did that, it all started working.

Thank you for this!  I too am using postgresql and I also had simply ran
/usr/libexec/bacula/update_bacula_tables.  Things looked ok until I
tried a test restore:

Building directory tree for JobId(s) 15256,15739,15762 ...  Query
failed: DECLARE _bac_cursor CURSOR FOR SELECT Path.Path, T1.Filename,
T1.FileIndex, T1.JobId, LStat, DeltaSeq  FROM ( SELECT DISTINCT ON
(Filename, PathId, DeltaSeq) JobTDate, JobId, FileId, FileIndex, PathId,
Filename, LStat , DeltaSeq FROM (SELECT FileId, JobId, PathId,
Filename, FileIndex, LStat ,DeltaSeq FROM File WHERE JobId IN
(15256,15739,15762) UNION ALL SELECT File.FileId, File.JobId, PathId,
Filename, File.FileIndex, LStat , DeltaSeq FROM BaseFiles JOIN File
USING (FileId) WHERE BaseFiles.JobId IN (15256,15739,15762) ) AS T JOIN
Job USING (JobId) ORDER BY Filename, PathId, DeltaSeq, JobTDate DESC  )
AS T1 JOIN Path ON (Path.PathId = T1.PathId) WHERE FileIndex > 0 ORDER
BY T1.JobTDate, FileIndex ASC: ERR=ERROR:  permission denied for table file

However, once I ran /usr/libexec/bacula/grant_bacula_privilege, that
problem was solved.  From what I can see, everything is working fine now.

John Florian

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

Re: vim has lost it's damn mind

[John Florian]

On 2020-07-28 17:09, John Florian wrote:
>
> I also have seen some weirdness of late, but I'm still on F31.  I had
> yaml files indented with sw=4 and my foldmethod=indent.  Now I have to
> open the fold twice, once for the invisible fold that seems to be
> implied as if sw=2 and one more to get the real thing.  If I reformat
> to use 2-space indents the folding works like I'd expect but something
> changed.  I've also gotten lots of pain with certain key combos that
> were solid for ages.  Ctrl-6 to swap buffers % and # now must be
> Ctrl-Shift-6 for vim, though the former still works in gvim.  I have a
> mapping for  :nohlsearch that I've used for over a decade to
> un-highlight a search.  That no longer works in vim or gvim.  Until
> I'd found that I figured something in konsole had changed.  But once
> gvim revealed weird issues I figured it must be more of a vim thing.
> Now seeing this message, I'm becoming even more certain.
>
I understand better now my problems with my mappings.  Above, I said I
had a mapping for  :nohlsearch.  In actuality, this was ^E
:nohlsearch.  Both should work but only the latter now only works
with vim; gvim shows the mapping with :map but I can't make it trigger.

I still don't know what's up with the yaml indenting.  I'll have to
check on the cindent setting that's been brought up recently.  I also
don't understand the new Ctrl-6 behavior, but I suspect that's konsole
that's changed.


John Florian

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

Re: vim has lost it's damn mind

[John Florian]

On 2020-07-28 17:58, Sergio Belkin wrote:
> Since a couple of years ago, I'm a happy user of neovim on Fedora :)


I play with it now and then but have yet to switch completely.  It's
been long enough that I don't remember what my hangup was.  If memory
serves, it was the lack of gneovim or whatever it'd be called.  There
was MUCH to be liked however, I remember that much.

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

Re: vim has lost it's damn mind

[John Florian]

I also have seen some weirdness of late, but I'm still on F31.  I had
yaml files indented with sw=4 and my foldmethod=indent.  Now I have to
open the fold twice, once for the invisible fold that seems to be
implied as if sw=2 and one more to get the real thing.  If I reformat to
use 2-space indents the folding works like I'd expect but something
changed.  I've also gotten lots of pain with certain key combos that
were solid for ages.  Ctrl-6 to swap buffers % and # now must be
Ctrl-Shift-6 for vim, though the former still works in gvim.  I have a
mapping for  :nohlsearch that I've used for over a decade to
un-highlight a search.  That no longer works in vim or gvim.  Until I'd
found that I figured something in konsole had changed.  But once gvim
revealed weird issues I figured it must be more of a vim thing. Now
seeing this message, I'm becoming even more certain.

John Florian

On 2020-07-25 09:21, Richard Shaw wrote:
> After upgrading to Fedora 32 I've noticed when editing files,
> especially spec files that vim does some crazy jumps/indents that it
> didn't do before.
>
> Right now I'm pressing i to insert a line before a Requires: and when
> I hit enter it jumps to the next line (fine) but with 4 indents and
> one space... WTF?
>
> Anyone else seeing strange vim behavior?
>
> Thanks,
> Richard
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Anyone using Tiled windows on Plasma out there ?

[John Florian]

On 2020-07-16 13:59, Sergio Belkin wrote:
>
>
> El jue., 16 jul. 2020 a las 12:22, John Florian
> (mailto:jflor...@doubledog.org>>) escribió:
>
> In any case, the few hassles I encounter are so much less time
> demanding
> than all the window management I manually did before adopting
> kwin-tiling.  If I could only have "focus follows eyes", I'd be quite
> happy in the WM serving me rather than the other way around.  :-)
>
>
> John Florian
>
>
> LoL
> I have set "focus follows mouse"
Same here; it's the next best thing.
> Actually what I find most useful is an hybrid approach. I mean, tiled
> windows, but sometimes I need to focus on only one windows and to
> maximize it :)
I too do this now and then and kwin-tiling is really good at allowing
this as well as allowing me to resize the windows for a temporary override.
> -- 
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Anyone using Tiled windows on Plasma out there ?

[John Florian]

On 2020-07-14 19:29, Sergio Belkin wrote:
> Yup, AFAIK  "Tiling Extension" is
> https://github.com/kwin-scripts/kwin-tiling. In fact, I think is the
> best option available, but it happens sometimes on non-weekend days
> that it becomes buggy and unstable, and it's pain, kwin crashes, I
> have to use openbox, to recover it the session control, but I think
> that is when I open Thunderbird for my job...

I have not experienced such crashes.  What I do encounter now and then
is the compositor being disabled due to it crashing and kwin-tiling very
much depends on the compositor.  My $HOME is mounted via NFS on several
workstations of various hardware quality.  Some have Nvidia and that
seems to be where most of my problems are.

My only other complaint is trying to move a separate chromium-browser
window into another so as to merge tabs.  That gets a little weird
because things seem confused as to whether I wish to make this one
browser window the new master or merge it into the master.  What I've
found works rather reliably is to make the window that's to receive the
tab the master and then drag the other tab into its tab bar.

In any case, the few hassles I encounter are so much less time demanding
than all the window management I manually did before adopting
kwin-tiling.  If I could only have "focus follows eyes", I'd be quite
happy in the WM serving me rather than the other way around.  :-)


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

Re: Anyone using Tiled windows on Plasma out there ?

[John Florian]

On 2020-07-14 13:42, Sergio Belkin wrote:
> What is the better option to to get tiled windows in Plasma?
>
> I've tried a few kwin scripts with no luck, for example:
>
> - Grid-Tiling
> - Krohnkite
> - Tiling Extension
>
> The best I've tried so far is the last one, but can be too unstable...
>
> What is your experience about it?
> -- 
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.org


I'm using and mostly quite happy with
https://github.com/kwin-scripts/kwin-tiling.  I didn't realize there
were so many options, so if anyone has used kwin-tiling and any of the
others, I'd be curious to hear opinions.

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

Re: kernel rpm split

[John Florian]

On 2020-02-07 09:56, Stephen John Smoogen wrote:



On Fri, 7 Feb 2020 at 09:28, Zbigniew Jędrzejewski-Szmek 
mailto:zbys...@in.waw.pl>> wrote:


On Fri, Feb 07, 2020 at 08:37:05AM -0500, Neal Gompa wrote:
> On Fri, Feb 7, 2020 at 8:27 AM Zbigniew Jędrzejewski-Szmek
> mailto:zbys...@in.waw.pl>> wrote:
> >
> > On Fri, Feb 07, 2020 at 12:09:37PM +, Richard W.M. Jones
wrote:
> > >
> > > I'd strongly suggest you look at supermin before going any
further.
> >
> > Supermin is an interesting project, but at this point we're not
> > looking for a tool to craft the image. We're still at an
earlier stage
> > of changing how we do some rpm packages so that it is easy to
do an
> > installation that is small without custom logic.
> >
> > The idea is that the initramfs, once you include lvm, md, dm,
encryption,
> > networking, clevis, emergency utilities, scsi, iscsi, raid in
various
> > flavours, some graphics drivers, usb, bluetooth, etc, is a lot
like a
> > the full distribution. Things would be a lot easier if we
could just
> > use the same tools and daemons from the same packages as in the
> > host. Supermin (and other tools) have support for creating
something
> > custom and small, and here the goal is the opposite: to do
"standard".
> >
> > Fedora currently uses dracut, and the problem is that nobody has a
> > good grasp on what goes in dracut. There's a lot of custom
logic and
> > custom code and reimplementation of things, and people who
deal with
> > the same functionality in the host system don't necessarily
know what
> > happens in the initramfs. In the past such a setup made sense,
but now
> > it seems that the tradeoffs are different.
> >
>
> I'm genuinely surprised by this. [...] The main problem with
> dracut is the same problem with all initramfs generators: it has to
> prepare an environment that works in the worst circumstances. It's
> compounded by the restriction that everything is written in
shell, and
> POSIX shell at that (because Debian).

Well, look at it from the other side: the host machine also needs to
work in the same circumstances, since we need things to work also
after
we switch to the host. And the actual code that we use in the host
— the libraries, the binaries, configuration — is the same, since we
don't do different compilations for the initramfs.
In the host we have switched away from the shell for machine boot, but
for some reason we still keep it for the initramfs, along with a large
amount of custom logic.

> The dracut package, while very large,
> has a pretty understandable framework model.
Sure, it *can* be understood, but should it? Do we gain anything by
having the initramfs so different from the host? The initial


My problem here is that we continually get told we are full of Not 
Invented Here(NIH) solutions by people in other communities and we 
should be doing something Debian and different communities use..


And here is one of the places we do agree with other distributions, 
but it is now a "bah its crap and you can do something better that 
works with your tools." We knew that years ago and we have known that 
time and time again. The issue is that we end up with another 'NIH' 
tool which our limited manpower are going to know and as soon as XYZ 
developer walks off to $ABC startup we have an unbootable and 
unmaintained mess. AKA where we were before dracut.


If we are hell bent on repeating history, please let us try to learn 
from it first.



Please allow me to weigh in here, whilst I straddle this fence since I 
have a vested stake here, though I only have $0.02 to vote with just 
like anyone else.


On one hand, I like the idea being proposed.  I mean, it shouldn't be 
that different of an environment than what you're trying to boot into.  
The whole process has a a lot of complexity that seems wasteful in some 
cases but affords flexibility in others.  Nobody likes waiting for 
dracut to do its thing.  I've literally done so hundreds of times in the 
last few weeks as I prepare for an in-service, in-place upgrade of 
several hundred nodes running a custom Fedora Live spin to a newer 
custom Fedora Live spin.  I've done so successfully shepherding them 
from Fedora 10 to 25 and am about to jump them all to F29.  The magic 
all happens via a custom initrd that does a switcheraroo of the LiveOS 
and syslinux directories.  So, one reboot into the magic initrd to do 
the switch and another reboot from there into the new distro. (I should 
note, that the hundreds of dracut runs are its fault, but instead for 
dev work related to how the new payload is managed.  Nonetheless, I've 
done a lot of waiting in testing due to dracut runs.)


On the other hand, I remember the madness of trying to maintain local 
patches 

Re: epel8: BuildrootError: could not init mock buildroot

[John Florian]

On 2020-02-05 15:41, Kevin Fenzi wrote:

On Mon, Feb 03, 2020 at 11:45:38AM -0500, John Florian wrote:

On 2020-01-30 20:42, Kevin Fenzi wrote:

I fear it's just bad timing + the external rhel8 repo we have only keeps
the newest packages (epel7 repos keep the old packages around too).

koji has no way to know that an external repo updated and needs
regeneration, so it just regenerates it when the buildroots that depend
on it change, ie, for epel8 that means when a stable updates push goes
out. Since updates pushes have been broken, no regen has happened
recently. ;( For epel7, it's fine just using the older package, but in
epel8 it's gone and you see the 404 for it.

Updates pushes should be going again so that should help.

After that I guess we could try and just do a regen every day no matter
what? Or add something to the script that updates the repo to fire one
after anything updates?

kevin

I don't know if it would be useful or not here, but you might want to check
out my gojira tool as part of https://github.com/jflorian/koji-helpers.

Cool. Do you know if upstream koji would be open to just merging this?

It would likely be handy for a lot of places that use external repos.

kevin


I've not approached them but have been wanting to do so.  I needed it 
for $DAYJOB (and wanted it for $NIGHTHOBBY) and it's proved itself 
worthwhile.  The hardest part for me was determining that indeed 
something like this is needed and that no, koji doesn't do that yet.


IIRC, I've seen that they've had discussions for something like this.  I 
had wanted to clean it up to use native calls rather than shelling to 
the koji cli, but was waiting until koji was on python 3 since I had 
never had any interest in taking this backwards to py2.  Then a divorce 
fell in my lap last year and I'm still sorting out that mess so, 
unfortunately, I don't have the time to shepherd this thru right now or 
in the immediate future that I can foresee.  If someone wishes to do 
that, I'd be more than happy to advise and answer any questions.


My timeline is also crunched while I try to figure out how to configure 
koji to build against EL8 and seem to be running into many problems that 
Fedora has faced with EPEL8 and Modularity, which may also affect all of 
this.  Somehow I got myself onto too many treadmills at once!  :-)

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

Re: epel8: BuildrootError: could not init mock buildroot

[John Florian]

On 2020-01-30 20:42, Kevin Fenzi wrote:

I fear it's just bad timing + the external rhel8 repo we have only keeps
the newest packages (epel7 repos keep the old packages around too).

koji has no way to know that an external repo updated and needs
regeneration, so it just regenerates it when the buildroots that depend
on it change, ie, for epel8 that means when a stable updates push goes
out. Since updates pushes have been broken, no regen has happened
recently. ;( For epel7, it's fine just using the older package, but in
epel8 it's gone and you see the 404 for it.

Updates pushes should be going again so that should help.

After that I guess we could try and just do a regen every day no matter
what? Or add something to the script that updates the repo to fire one
after anything updates?

kevin


I don't know if it would be useful or not here, but you might want to 
check out my gojira tool as part of 
https://github.com/jflorian/koji-helpers.

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

Re: Git Forge Requirements: Please see the Community Blog

[John Florian]

On 2020-01-23 11:26, Bruno Wolff III wrote:

On Wed, Jan 22, 2020 at 10:28:52 -0500,
 Neal Gompa  wrote:


We don't need to. There are improvements that people would like, and
that does take development effort. That's the piece that requires
manpower to go faster.


In my opinion, I think this is where Red Hat should be helping. Pagure 
has a chance to change what free projects use for software 
development. Github isn't free (though they do some nice things for 
free software). Gitlab is open core, which means they have a conflict 
of interest when accepting improvements from outsiders. They could 
also stop supporting the open core at any time, leaving users who want 
infrastructure running on free software in a poor place.



I completely agree with this.  I find it rather bizarre that I came to 
know FOSS almost exclusively because of Red Hat, yet it seems the 
majority of the projects I contribute to are now being hosted on Github, 
a Microsoft-owned company.  I'd be rather incredulous if someone told me 
it was going to be like this back in the 90s.  I've little experience 
with Gitlab, but plenty with Pagure from an internal instance and a few 
projects on pagure.io like Koji.  I love Pagure and all this talk of 
possibly pushing it aside for Fedora makes me sad.  I thought it was the 
way forward and was just getting to an excellent footing.  Pagure might 
not be a money-making product but it sure can help build a community in 
an environment that is void of any potential corporate hostility.

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

Re: Let's talk about Fedora in the '20s!

[John Florian]

On 1/7/20 10:28 AM, Matthew Miller wrote:

On Tue, Jan 07, 2020 at 03:22:45PM +0100, Iñaki Ucar wrote:

For me, the main challenge Fedora faces is **positioning**.

Let me explain: (I don't have numbers but) in my (limited) experience,
when seasoned sysadmins need to launch a new system, they usually
think "Debian" as something reliable; when seasoned as well as
not-very-seasoned-in-Linux research engineers (I know better this
category, since I'm a researcher) need to setup a system for some demo
or experiment, they mostly think "Ubuntu" (yes, I know...); when we
see a new exciting service (such as Travis CI and the like) coming
out, they usually support Ubuntu; and so on and so forth, and I'm not
even talking about the desktop use case.

So I think there's the challenge for Fedora, for all those people to
consider Fedora as a first option for their use cases.

I agree that's a challenge. Any ideas for how to address it and change these
perceptions?

Here's one that should be easy, though it probably won't have the 
desired impact, but we should practice what we preach, at minimum: make 
Fedora a selection for the OS in oVirt.  I wind up choosing the latest 
RHEL for all my Fedora VMs but I always have to wonder if that's optimal 
-- and I've lived in the shade of RH since the RHL4.0 days.  Why do we 
have to guess at this?  I know oVirt isn't a Fedora project, it's a RH 
one, but this should be one upstream that's the easiest of all to 
convince.  I mean Ubuntu is a choice here!  What kind of message does 
this project to you?

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

No rich dependencies allowed for this type on *.desktop files

[John Florian]

I think I found a bug and am hoping someone here can point me in the 
right direction as to where to report it.  I think this is rpmbuild, but 
am not certain.


Anyway, I have a private package that generates a bunch of desktop files 
for our users.  Both the filename and Name= values inside the desktop 
file contain a parenthetical hint to the user. Builds prior to F31 have 
had no issue, but with F31 now things fail.  Here's an example desktop 
file that fails:


~~~
# PICAPS 0001-Mason (Michigan).desktop
[Desktop Entry]
Type=Application
Name=PICAPS 0001-Mason (Michigan)
Categories=Network;RemoteAccess;
Icon=utilities-terminal
Exec=picaps mdct-01pi
Terminal=false
~~~

The failure I see in Koji's build.log looks like this:

~~~
+ cp -pr CHANGELOG.md 
/builddir/build/BUILDROOT/plant-launchers-1.15.0-2.git.2.69f8c70.fc31.noarch/usr/share/doc/plant-launchers
+ cp -pr README.md 
/builddir/build/BUILDROOT/plant-launchers-1.15.0-2.git.2.69f8c70.fc31.noarch/usr/share/doc/plant-launchers

+ RPM_EC=0
++ jobs -p
+ exit 0
error: No rich dependencies allowed for this type: (Idaho).desktop)

error: No rich dependencies allowed for this type: (Michigan).desktop)

Child return code was: 1
EXCEPTION: [Error()]
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/mockbuild/trace_decorator.py", 
line 95, in trace

    result = func(*args, **kw)
  File "/usr/lib/python3.7/site-packages/mockbuild/util.py", line 746, 
in do_with_status
    raise exception.Error("Command failed: \n # %s\n%s" % (command, 
output), child.returncode)

mockbuild.exception.Error: Command failed:
 # /usr/bin/systemd-nspawn -q -M 2145c769ea5744e7b70b9eb2ca4e7029 -D 
/var/lib/mock/f31-build-8562-11880/root -a --capability=cap_ipc_lock 
--bind=/tmp/mock-resolv.el3vagqj:/etc/resolv.conf --setenv=TERM=vt100 
--setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock 
--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin 
--setenv=PROMPT_COMMAND=printf "\033]0;\007" 
--setenv=PS1= \s-\v\$ --setenv=LANG=en_US.UTF-8 -u 
mockbuild bash --login -c /usr/bin/rpmbuild -bb --target noarch --nodeps 
/builddir/build/SPECS/plant-launchers.spec

~~~


I haven't done a ton with rich deps yet but I cannot imagine these are 
being driven from desktop files now ... or are they? Another thing odd I 
see here is the trailing ')' in the error message.  It doesn't seem to 
have a mate and I'm guessing it comes from the format string for 
printing this error.


I've worked around this problem by avoiding the parenthesis like so:

~~~
# PICAPS 0001-Mason, Michigan Test.desktop
[Desktop Entry]
Type=Application
Name=PICAPS 0001-Mason, Michigan Test
Categories=Network;RemoteAccess;
Icon=utilities-terminal
Exec=picaps mdct-01pt
Terminal=false
~~~
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Estimate the size of iso file based on a kickstart file

[John Florian]

On 9/19/19 8:25 AM, Nico Kadel-Garcia wrote:
> On Thu, Sep 19, 2019 at 8:11 AM Kalpa Welivitigoda  
> wrote:
>> Hi all,
>>
>> Given a kickstart file (flatten) and we intend to make an iso using
>> it, is there a tool or service by which we can estimate the size of
>> the final iso (based on the packages defined in the kickstart file)
>> before actually creating the iso?
> Since a kickstart file can refer to RPM's stored on the ISO file, or
> on a separate website, and those RPM's are the majority of the bulk of
> an installation DVD, it's not clear you can gracefully do this. A
> single RPM file can drag in a *lot* of dependencies that may change
> based on upstream updates. Why try to guess rather than simply running
> the tool, which will be pretty fast if you work from a local yum
> mirror?


Doesn't anaconda do a test to see if the install will fit?  I vaguely
recall (or imagine, with age it seems there's little difference
sometimes) seeing such a message.  If so, that would handle all the
dependency recursion and from there a statistical factor for the
expected compression should get a reasonably close estimate, no?

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

Re: BackupPC selinux help

[John Florian]

On 2019-09-04 10:40, Richard Shaw wrote:
On Wed, Sep 4, 2019 at 9:36 AM John Florian <mailto:jflor...@doubledog.org>> wrote:


On 2019-08-30 13:51, Richard Shaw wrote:
> He's already tried restorecon, changed from a symlink to a bind
mount
> (for the backup root)...

Maybe a dumb Q, but have you tried doing the same?  Maybe it's
your host
that's not per defaults.


I'm not quite sure what you mean. I don't have the problem with my 
install and I haven't been able to reproduce the problem.
I mean have *you* ran restorecon?  Could it be that your host is simply 
mislabeled?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: BackupPC selinux help

[John Florian]

On 2019-08-30 13:51, Richard Shaw wrote:
He's already tried restorecon, changed from a symlink to a bind mount 
(for the backup root)...



Maybe a dumb Q, but have you tried doing the same?  Maybe it's your host 
that's not per defaults.

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

Re: Rolling out Phase I of rawhide package gating

[John Florian]

On 2019-07-31 21:35, Jason L Tibbitts III wrote:

"NG" == Neal Gompa  writes:

NG> You just set localpkg_gpgcheck=1 in /etc/dnf/dnf.conf

NG> That said, you probably don't want to do that, since most downloaded
NG> packages aren't signed...
Cool!  I wasn't even aware of this setting.  Can we set that and then 
override with --nogpgcheck for the exceptions?


I think that the ideal behavior would be to always check, but
warn/prompt for unsigned packages or those with signature failures.
Certainly it's better to verify as much as possible as often as
possible.

That would be even better, except maybe when scripting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Qt Wayland By Default on Gnome

[John Florian]

On 2019-06-28 18:28, Kevin Kofler wrote:

Quoting from the proposal:

Qt Wayland plugin has been available for a long time, but it hasn't
been in condition where it could be enabled by default. With Qt 5.12
the state of the Wayland plugin is much better and it's becoming more
and more reliable. It now supports all the needed protocols

Actually, the primary selection protocol (middle-click paste) is only
supported in Qt ≥ 5.14 (not released yet). (It also requires a compositor
implementing the final specification. I'm not sure whether GNOME Shell
already moved from the GNOME private version to the upstreamed version of
the protocol.)



Along these lines, what's the status of Plasma on Wayland?  Any idea 
when this might become the default way of running Plasma on Fedora?

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

Re: two Ceph updates for f28, f29, stuck in pending testing for six days

[John Florian]

On 3/22/19 3:07 PM, Kevin Fenzi wrote:

On 3/21/19 5:45 PM, Kaleb Keithley wrote:

On Tue, Feb 19, 2019 at 3:18 AM Kevin Fenzi  wrote:


On 2/18/19 12:56 PM, Kaleb Keithley wrote:

https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8
https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a

Would someone please give them a kick?

For some reason autosign likes to not process these correctly.

I've retagged them to get it to do another pass...

Sorry for not fixing them sooner.


Looks like another Ceph build is stuck.

  https://bodhi.fedoraproject.org/updates/FEDORA-2019-16c36506c1

Would someone kick it please? Thanks

Fixed, and I looked and asked upstream and this is fixed in sigul 1.0.

So, hopefully we won't have to keep doing this too much longer.

kevin


Hey Kevin, might I ask what fp.o is using for hosting sigul or package 
signing these days?  I have a private setup that works on EL7 using a 
special builder-rpms.repo, thanks to your help some years ago, but that 
version seems to be quite dated now.  I've tried recently putting both 
on F29 but the Server was an absolute no go -- IIRC due to the whole 
gpgme incompatibilty mess.  I can get the Bridge to run on F29 but it 
goes wonky if left inactive for too long ... something like overnight is 
enough.  Meanwhile, things like [0] make it look orphaned (see Assignee) 
and FTBFS for F30 [1].


[0] https://bugzilla.redhat.com/show_bug.cgi?id=1701923

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1675996
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: latest rubygem-puppet-lint for F29 is from F23???

[John Florian]

On 3/30/19 7:54 AM, Fabio Valentini wrote:

On Sat, Mar 30, 2019 at 1:20 AM John Florian  wrote:

On 3/29/19 2:58 PM, Vít Ondruch wrote:

Dne 29. 03. 19 v 19:47 John Florian napsal(a):

I know it's not unusual to carry builds over from prior releases.  My
understanding is that happens because there was no mass rebuild.
However, when I look at the F29 repo I see
rubygem-puppet-lint-1.1.0-2.fc23.noarch.rpm.  Was there really no mass
rebuild between F23 and F29?  This package is severely outdated --
upstream has v2.3.6 and v1.1.0 dates back to 2014.  It looks like a
build hasn't succeeded in Koji since F23.  I don't know why because I
don't see any build logs for any of these failures.  I also was under
the impression that FTBS packages like this get culled.

Is my understanding buggy or did this leak through somehow?


You can see that all mass rebuilds failed:

https://koji.fedoraproject.org/koji/packageinfo?packageID=14781

And there are several FTBFS bugs reported (including closed due to EOL):

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=CLOSED=rubygem-puppet-lint_id=10071090=Fedora=Fedora%20EPEL_format=advanced

Looking at the logs from the oldest bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1308068

I guess the origin of the issues is that it does not yet use
%gem_install macro and the rubygems `--rdoc` option was deprecated
around F24 time.


And it looks like the maintainer is MIA in all that time ... not a
single response:

https://bugzilla.redhat.com/show_bug.cgi?id=1349208

Looking at src.fp.org, this is the only package that's associated with
this maintainer.
So I think in this case you can safely initiate the "Nonresponsive
Maintainer" process ...

Fabio
I wish I had the time to pursue this as I've been wanting to get more 
involved in Fedora packaging (as opposed to the gobs of 
private/corporate packaging I've been doing) for years.  I finally got 
around to getting sponsored and since then my life has become a complete 
turmoil.  Sadly, this looks just about my speed if I did have the time.  
Nonetheless, shouldn't this have been culled for FBTFS?

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

Re: Understanding Fedora's use of systemd presets and packaging requirements

[John Florian]

On 4/22/19 12:25 PM, Adam Williamson wrote:

On Sat, 2019-04-20 at 07:59 +, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Apr 19, 2019 at 04:35:54PM -0400, John Florian wrote:

I'm generally familiar with how systemd presets work but I'm at a
bit of loss as to how part of all the magic works.  To best explain
my confusion, let me say that I make a customized live spin of
Fedora and I have a package we'll call "my-dist" which is similar in
nature to the "fedora-release" package in that it provides a custom
preset file.  I still use fedora-release because this spin is not
*that* customized, so it's best to think of this as an extension.  I
have another package we'll call "my-service" which has a systemd
service unit file and all the usual %systemd_post, etc. macros.
When I boot my live spin I find that my-service is not enabled
despite the preset in my-dist.  I can "systemctl preset-all" to
rectify this so I believe most requirements are correct.  I do see
that livemedia-creator installs my-service *before* it installs
my-dist so if the %systemd_post is called as each rpm is installed
that would explain my problem because my custom preset isn't present
yet.

How does Fedora itself accomplish this???  I don't see every package
providing a service having a dependency on fedora-release to address
this ordering issue.  I can certainly stick the "systemctl
preset-all" into the %post of my kickstart as final cleanup, but
that feels dirty and wrong.  Similarly, I don't wish to have to have
a "Requires: my-dist" in every one of "my-service" and other
packages like it.  I've scrutinized fedora-release.spec and didn't
see anything all that different than what I have in my-dist.

systemd.rpm does preset-all when it is installed, so it is enough
that systemd.rpm is installed after fedora-release-common.rpm.
fedora-release-common is required by setup.rpm, so it is installed
early. But you raise a good point — I don't see any *explicit*
ordering chain between fedora-release-common and systemd.

There is no need to order individual rpms against either
fedora-release-common and other packages providing presets or
systemd. The only thing that is necessary is for systemd.rpm to be
installed after all presets. If that is satisfied, packages proving
services can be installed both earlier and later and the effect
(in the sense of service enablement) should be identical.

AIUI, the design is that any package that *ships a preset* should run
systemctl preset on it in its scriptlets (there should be guidelines
for this somewhere but I can't find them right now). However, there's a
loophole here in that if any package that ships a preset gets ordered
before systemd itself during install, its attempt to run 'systemctl
preset' will obviously fail. This is why we run 'preset-all' in the
systemd package scriptlets: to apply the presets for any packages which
were already installed. It's not intended that all other packages can
*rely* on the call in systemd's scripts.

So, basically: if you're making a package that includes presets, run
'systemctl preset' on the presets it ships in its scripts. Not 'preset-
all', but run it specifically per preset that you ship.


Ahha!  That was worded perfectly for me to recognize where I erred.  All 
the other comments were doing great things for my understanding, but 
this put the spotlight just right.  I have numerous services I use to 
transform Fedora into a stateless appliance OS, but I went too far in 
mimic what I saw from Fedora itself.  Each of my packages that provides 
a service do indeed use the wonderful systemd scriptlets, but all of my 
presets ship in separate package ("my-dist" from above) that kind of 
mimics fedora-release (and its 
/usr/lib/systemd/system-preset/90-default.preset file).  This my-dist 
package doesn't use the scriptlets at all since I didn't see that in 
fedora-release.spec.  I went this route because I wanted to capture the 
policy of each of my custom services all in one place, much like the 
aforementioned file does for Fedora.

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

Re: Understanding Fedora's use of systemd presets and packaging requirements

[John Florian]

On 4/22/19 12:31 PM, Adam Williamson wrote:

On Mon, 2019-04-22 at 09:25 -0700, Adam Williamson wrote:

On Sat, 2019-04-20 at 07:59 +, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Apr 19, 2019 at 04:35:54PM -0400, John Florian wrote:

I'm generally familiar with how systemd presets work but I'm at a
bit of loss as to how part of all the magic works.  To best explain
my confusion, let me say that I make a customized live spin of
Fedora and I have a package we'll call "my-dist" which is similar in
nature to the "fedora-release" package in that it provides a custom
preset file.  I still use fedora-release because this spin is not
*that* customized, so it's best to think of this as an extension.  I
have another package we'll call "my-service" which has a systemd
service unit file and all the usual %systemd_post, etc. macros.
When I boot my live spin I find that my-service is not enabled
despite the preset in my-dist.  I can "systemctl preset-all" to
rectify this so I believe most requirements are correct.  I do see
that livemedia-creator installs my-service *before* it installs
my-dist so if the %systemd_post is called as each rpm is installed
that would explain my problem because my custom preset isn't present
yet.

How does Fedora itself accomplish this???  I don't see every package
providing a service having a dependency on fedora-release to address
this ordering issue.  I can certainly stick the "systemctl
preset-all" into the %post of my kickstart as final cleanup, but
that feels dirty and wrong.  Similarly, I don't wish to have to have
a "Requires: my-dist" in every one of "my-service" and other
packages like it.  I've scrutinized fedora-release.spec and didn't
see anything all that different than what I have in my-dist.

systemd.rpm does preset-all when it is installed, so it is enough
that systemd.rpm is installed after fedora-release-common.rpm.
fedora-release-common is required by setup.rpm, so it is installed
early. But you raise a good point — I don't see any *explicit*
ordering chain between fedora-release-common and systemd.

There is no need to order individual rpms against either
fedora-release-common and other packages providing presets or
systemd. The only thing that is necessary is for systemd.rpm to be
installed after all presets. If that is satisfied, packages proving
services can be installed both earlier and later and the effect
(in the sense of service enablement) should be identical.

AIUI, the design is that any package that *ships a preset* should run
systemctl preset on it in its scriptlets (there should be guidelines
for this somewhere but I can't find them right now). However, there's a
loophole here in that if any package that ships a preset gets ordered
before systemd itself during install, its attempt to run 'systemctl
preset' will obviously fail. This is why we run 'preset-all' in the
systemd package scriptlets: to apply the presets for any packages which
were already installed. It's not intended that all other packages can
*rely* on the call in systemd's scripts.

BTW if you're wondering "why not just make sure everything that ships a
preset gets installed after systemd"...sadly there are some awkward
cases that make that not practical, basically 'systemd depends on
something that installs a preset' or 'systemd depends on something that
depends on something that installs a preset'.

I hadn't yet, but probably would've eventually, so thanks for this!!!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Understanding Fedora's use of systemd presets and packaging requirements

[John Florian]

On 4/20/19 3:59 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Apr 19, 2019 at 04:35:54PM -0400, John Florian wrote:

I'm generally familiar with how systemd presets work but I'm at a
bit of loss as to how part of all the magic works.  To best explain
my confusion, let me say that I make a customized live spin of
Fedora and I have a package we'll call "my-dist" which is similar in
nature to the "fedora-release" package in that it provides a custom
preset file.  I still use fedora-release because this spin is not
*that* customized, so it's best to think of this as an extension.  I
have another package we'll call "my-service" which has a systemd
service unit file and all the usual %systemd_post, etc. macros.
When I boot my live spin I find that my-service is not enabled
despite the preset in my-dist.  I can "systemctl preset-all" to
rectify this so I believe most requirements are correct.  I do see
that livemedia-creator installs my-service *before* it installs
my-dist so if the %systemd_post is called as each rpm is installed
that would explain my problem because my custom preset isn't present
yet.

How does Fedora itself accomplish this???  I don't see every package
providing a service having a dependency on fedora-release to address
this ordering issue.  I can certainly stick the "systemctl
preset-all" into the %post of my kickstart as final cleanup, but
that feels dirty and wrong.  Similarly, I don't wish to have to have
a "Requires: my-dist" in every one of "my-service" and other
packages like it.  I've scrutinized fedora-release.spec and didn't
see anything all that different than what I have in my-dist.

systemd.rpm does preset-all when it is installed, so it is enough
that systemd.rpm is installed after fedora-release-common.rpm.
fedora-release-common is required by setup.rpm, so it is installed
early. But you raise a good point — I don't see any *explicit*
ordering chain between fedora-release-common and systemd.

There is no need to order individual rpms against either
fedora-release-common and other packages providing presets or
systemd. The only thing that is necessary is for systemd.rpm to be
installed after all presets. If that is satisfied, packages proving
services can be installed both earlier and later and the effect
(in the sense of service enablement) should be identical.

Zbyszek
Thank you for the nicely detailed answer.  So if there's no explicit 
ordering chain in Fedora, does it mean that it's just luck to make it 
all work out?  If I read that right, it would seem that systemd would 
have to be one of the very last packages installed, but maybe it doesn't 
matter much for Fedora proper given how most everything is disabled by 
default.  Should I try to achieve that with my spin or is there even a 
way?  It would seem I would need some sort of reverse Requires to 
achieve this without touching Fedora's native packages.  I'm guessing 
that means doing a "systemctl preset-all" at the end of my kickstart is 
probably as good a solution as any.

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

Re: Basic graphics mode / 'nomodeset' testing request, round 2

[John Florian]

On 4/19/19 4:48 PM, John Florian wrote:
Might this be related to why my console goes blank without 'nomodeset' 
for my custom F29 live spins when I run them in QEMU? The problem just 
turned up about 2 weeks ago.  I don't see that message in the journal 
and thus far have only seen the problem when I run the images with QEMU.



Disregard this, I think.  I now see this is working for me and in 
comparing a good one and a bad one I see both have 
kernel-5.0.7-200.fc29.x86_64.  Unless there's some other package I 
should be seeing if it changed recently.

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

Re: Basic graphics mode / 'nomodeset' testing request, round 2

[John Florian]

Might this be related to why my console goes blank without 'nomodeset' 
for my custom F29 live spins when I run them in QEMU? The problem just 
turned up about 2 weeks ago.  I don't see that message in the journal 
and thus far have only seen the problem when I run the images with QEMU.


On 4/8/19 9:02 PM, Adam Williamson wrote:

Hi folks!

A few weeks back we asked for testing of 'basic graphics mode' /
nomodeset booting - the feedback from that was very helpful in
establishing that we had a generic issue which dated back to Fedora 29,
thanks a lot. We have now established more or less what that initial
issue is, and work is ongoing to get it fixed entirely. However, it's
already been fixed *partially*, and that revealed a subsequent bug.

The initial bug is fixed for the case of UEFI native boots (it is not
fixed for BIOS native boots yet). However, in testing, I and others
found that several UEFI test systems still do not boot successfully to
GDM, because they run into a *different* bug later:

https://bugzilla.redhat.com/show_bug.cgi?id=1693409

This bug can be identified by the presence of the following string in
the journal:

"(EE) Cannot run in framebuffer mode. Please specify busIDsfor
all framebuffer devices"

(yes, with a bunch of spaces - but just the first part of the line is
sufficient to identify the problem, I think).

It would be great if folks with UEFI-capable systems could try booting
a recent Fedora 30 Workstation live image on them, e.g. this one:

https://kojipkgs.fedoraproject.org/compose/branched/Fedora-30-20190408.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-30-20190408.n.0.iso

ensure you boot in UEFI mode. Please report back whether it works. If
it doesn't work, please check the logs - you should be able to log into
a console on tty3 (ctrl-alt-f3 to get there) as root with no password,
then run 'journalctl -b' to see the logs - and report if that line is
present or not. If it isn't, it'd be useful to know if some other error
message is present.

Thanks a lot, folks!

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

Understanding Fedora's use of systemd presets and packaging requirements

[John Florian]

I'm generally familiar with how systemd presets work but I'm at a bit of 
loss as to how part of all the magic works.  To best explain my 
confusion, let me say that I make a customized live spin of Fedora and I 
have a package we'll call "my-dist" which is similar in nature to the 
"fedora-release" package in that it provides a custom preset file.  I 
still use fedora-release because this spin is not *that* customized, so 
it's best to think of this as an extension.  I have another package 
we'll call "my-service" which has a systemd service unit file and all 
the usual %systemd_post, etc. macros.  When I boot my live spin I find 
that my-service is not enabled despite the preset in my-dist.  I can 
"systemctl preset-all" to rectify this so I believe most requirements 
are correct.  I do see that livemedia-creator installs my-service 
*before* it installs my-dist so if the %systemd_post is called as each 
rpm is installed that would explain my problem because my custom preset 
isn't present yet.


How does Fedora itself accomplish this???  I don't see every package 
providing a service having a dependency on fedora-release to address 
this ordering issue.  I can certainly stick the "systemctl preset-all" 
into the %post of my kickstart as final cleanup, but that feels dirty 
and wrong.  Similarly, I don't wish to have to have a "Requires: 
my-dist" in every one of "my-service" and other packages like it.  I've 
scrutinized fedora-release.spec and didn't see anything all that 
different than what I have in my-dist.

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

Re: latest rubygem-puppet-lint for F29 is from F23???

[John Florian]

On 3/29/19 2:58 PM, Vít Ondruch wrote:
> Dne 29. 03. 19 v 19:47 John Florian napsal(a):
>> I know it's not unusual to carry builds over from prior releases.  My
>> understanding is that happens because there was no mass rebuild. 
>> However, when I look at the F29 repo I see
>> rubygem-puppet-lint-1.1.0-2.fc23.noarch.rpm.  Was there really no mass
>> rebuild between F23 and F29?  This package is severely outdated --
>> upstream has v2.3.6 and v1.1.0 dates back to 2014.  It looks like a
>> build hasn't succeeded in Koji since F23.  I don't know why because I
>> don't see any build logs for any of these failures.  I also was under
>> the impression that FTBS packages like this get culled.
>>
>> Is my understanding buggy or did this leak through somehow?
>>
> You can see that all mass rebuilds failed:
>
> https://koji.fedoraproject.org/koji/packageinfo?packageID=14781
>
> And there are several FTBFS bugs reported (including closed due to EOL):
>
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=CLOSED=rubygem-puppet-lint_id=10071090=Fedora=Fedora%20EPEL_format=advanced
>
> Looking at the logs from the oldest bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1308068
>
> I guess the origin of the issues is that it does not yet use
> %gem_install macro and the rubygems `--rdoc` option was deprecated
> around F24 time.


And it looks like the maintainer is MIA in all that time ... not a
single response:

https://bugzilla.redhat.com/show_bug.cgi?id=1349208


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

latest rubygem-puppet-lint for F29 is from F23???

[John Florian]

I know it's not unusual to carry builds over from prior releases.  My
understanding is that happens because there was no mass rebuild. 
However, when I look at the F29 repo I see
rubygem-puppet-lint-1.1.0-2.fc23.noarch.rpm.  Was there really no mass
rebuild between F23 and F29?  This package is severely outdated --
upstream has v2.3.6 and v1.1.0 dates back to 2014.  It looks like a
build hasn't succeeded in Koji since F23.  I don't know why because I
don't see any build logs for any of these failures.  I also was under
the impression that FTBS packages like this get culled.

Is my understanding buggy or did this leak through somehow?

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

Re: /etc/yum.repos.d -> /etc/distro.repos.d

[John Florian]

On 3/13/19 8:41 AM, Neal Gompa wrote:

That said, I think if we want to move the repo files now, we should
also consider making so package installed repo and GPG files are in
/usr/share and that admin additions/overrides can be stored in /etc.
Same goes for vars and other such stuff.

That's more or less the mechanism we've adopted for tons of other
things, and it'd be nice to have it in DNF too...



Yes!  This.

I would also suggest that the canonical location be defined in another 
file whose name is as immutable as possible.  If there were a central 
file that held such important locations and all tools consulted that 
first, these kind of changes would be far less painful.  I'm thinking 
along the lines of the blessed sanity that /etc/os-release brings.  
Obviously it'll take a long time for it to have the far reaching 
benefits it could provide, but if we never start down that path...

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

Re: sqlite + django pains and serious bodhi confusion

[John Florian]

On 1/7/19 5:04 PM, Jason L Tibbitts III wrote:
>>>>>> "JF" == John Florian  writes:
> JF> I thought I'd start by consulting
> JF> https://bodhi.fedoraproject.org/updates/?packages=sqlite to see what
> JF> changed but much to my surprise the newest build I see there is
> JF> sqlite-3.22.0-5.fc28! Huh? Where are the f29 builds?
>
> First, note that Bodhi doesn't show builds, it shows updates.  It
> wouldn't show builds for F29 made early in that version's development
> cycle.
Ah, I see now.  3.26 just happens to be the first update. I think I knew
Bodhi is only updates, but for some reason I had a broken brain today.
> Second, it appears to me that the first line from that URL is
> "spatialite-tools-4.3.0-31.fc29 sqlite-3.26.0-1.fc29".  That's a single
> update which contained two packages.
Bingo!  I completely missed that there were two packages there.  They
just sort of blend in together to these old eyes.  I don't know that
I've ever seen this in Bodhi before ... not that am that frequent of a user.
>   Is that not what you were looking
> for? It does appear that spatiallite-tools and sqllite update together
> quite often, but I don't see how that could be considered to be a
> problem.

Nope, not a problem.  My confusion above explains it all.  Thanks Jason!

Also for anyone else reading, the python3-django-2.0.10-1.fc29
updates-testing right now does resolve the incompatibility problems with
this latest sqlite update.

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

sqlite + django pains and serious bodhi confusion

[John Florian]

After upgrading this morning I ran into some nasty issues with 
sqlite-3.26.0-1.fc29 which seems utterly broken now with 
python3-django-2.0.9-1.fc29 as described in this bug[0].  I thought I'd 
start by consulting 
https://bodhi.fedoraproject.org/updates/?packages=sqlite to see what 
changed but much to my surprise the newest build I see there is 
sqlite-3.22.0-5.fc28!  Huh?  Where are the f29 builds?  I only found the 
very helpful bug report after clicking through on the newest related 
build[1] for spatialite-tools (whatever that is) and only then because 
@plotrp "Clicked wrong -1 button".  So a quick downgrade of sqlite (back 
to sqlite-3.24.0-2.fc29) gets me going for now, but what's up with Bodhi?


[0] https://code.djangoproject.com/ticket/29182

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

Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[John Florian]

On 11/26/18 3:53 PM, Kevin Fenzi wrote:

The one issue I see off hand is that koji
tags are kind of expensive so we can't just tag everything the way we
may want


Can you please elaborate a bit on this?  What makes them expensive?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is Fedora 27 EOL?

[John Florian]

On 11/26/18 9:40 AM, Florian Weimer wrote:

There has been no EOL announcement, my guess for the EOL data
(2018-11-30) has not passed yet


At the very least, I don't recall seeing the announcement that it will 
be EOL in ~30 days.

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

Re: Fedora Lifecycles: imagine longer-term possibilities

[John Florian]

On 11/14/18 7:54 PM, mcatanz...@gnome.org wrote:
On Wed, Nov 14, 2018 at 4:42 PM, John Florian  
wrote:
I still don't understand what makes updating these for a *new* 
release significantly easier than an *existing* one. So let's 
just say GNOME (or whatever) comes out next month with a new major 
release we want to showcase. Why is it necessary to have a 
Fedora 30 to be able to realize this update. What is so 
difficult about providing this for Fedora 29. I'm trying to 
understand why these upstream updates can't be decoupled from the 
Fedora release schedule.


It's all a matter of QA. The freeze, the blocker bug process, and the 
quantity of users who test the stuff for us. We'd need major changes 
to our updates process to account for this in a mid-release update. 
The blocker bugs process would be needed, for a single bodhi update. 
At leas t a month or two of testing (during which new versions of the 
update will be released, so the update will have to go through some 
iterations). And lots and lots of testers: currently we get those for 
free because tons of people help us test beta releases of Fedora, I 
think far more than run updates-testing.
I think if we did this right, however it looks, multiple testing repos, 
rings, modularity, whatever... we might easily attract more testers than 
we have now.  I think this whole problem can usually be distilled down 
to, "I want LTS for everything because I hate breakage and I hate tech 
treadmills because I've already got too much to do.  Except for Foo, the 
version every other distro has is too old and I'm willing to get dirty 
if necessary because Foo is what matters to me."


This is all doable and solvable. Not a blocker. But if we don't take 
it seriously and make some big changes in how we release updates, it 
won't go well. Not well at all. So I'd recommend against it, unless 
there is some major benefit available from doing so.


I totally agree, but we are talking about radical changes here and I 
think we should keep all options on the table.  If some particular path 
forward is overwhelmingly desirable, that is the time to decide if the 
push is worth it, not earlier IMHO.  If the proposal, whatever it be, is 
great and everyone  agrees its great, the seriousness will be 
automatic.  Fedora has a long history of catering to some niche ideals 
that parts of our community are dead against.  It's awesome that Fedora 
is so flexible, but if we're going to fiddle with the release model, 
lets find something we *all* get behind and be happier with for the next 
15 years, however radical it might look like right now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[John Florian]

On 11/14/18 4:38 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Nov 14, 2018 at 12:37:46PM -0500, John Florian wrote:

On 11/14/18 10:36 AM, mcatanz...@gnome.org wrote:

We need to rebase GNOME within about two months of the new
upstream releases, or we'll lose our edge with the GNOME
community. We'd be ceding our position as best GNOME distro to
Ubuntu and Arch.

It seems wrong that a DE, even if it's the default, has so much sway
over the distro as a whole.

It's not just gnome. It's also gcc, glibc, boost, systemd, python, and
any other project which cannot be upgraded easily mid-cycle. Having
a chance to push a new version every six months is much better than
waiting a year.
I still don't understand what makes updating these for a *new* release 
significantly easier than an *existing* one.  So let's just say GNOME 
(or whatever) comes out next month with a new major release we want to 
showcase.  Why is it necessary to have a Fedora 30 to be able to realize 
this update.  What is so difficult about providing this for Fedora 29.  
I'm trying to understand why these upstream updates can't be decoupled 
from the Fedora release schedule.



So a one-year cycle means a major GNOME version update will need
to land in the middle of a release to avoid that. And these do not
have a good reputation for stability. Basically we'll wind up with
a bunch of bugs landing halfway through the release, and without
the usual Fedora QA process to ensure the most important of them
get fixed before they reach users.

Why can't GNOME be updated mid-release like any other application?
Why does the QA process require the cadence of the whole distro
release process to bend to GNOME?  Can't a major GNOME update land
in the testing repos to have QA issues sorted out there just as well
as in some alpha/beta release of the overall Fedora?

For me, any discussions about .1 or .5 completely miss the point.
The numbering does not matter at all, the freeze and the testing and
bugfixing matters. If we do it every 6 months, we might just as well
call this a new release each time.

As mentioned elsewhere in this thread, we have plenty of technical
issues to solve, including security bugs and whatnot. Let's not get
distracted by numbering.
I agree the numbering is irrelevant... I never said it was.  It was said 
or implied that QA works better *between* releases and I don't see why 
that cannot occur for a release that's already out the door.  I mean 
isn't that what the testing repos are for?  So I'm proposing to partly 
evolve to a sort of rolling distro.  If the schedule decoupling can 
occur, it should then be possible to move Fedora to a yearly release 
schedule, provide a 6 month upgrade window and reduce maintainer burden 
because there's only 1 or 2 supported releases instead of 2 or 3.  That 
would mean releases are supported for 18 months instead of 13.  Change 
the periods how you wish, but the decoupling would allow getting longer 
support while requiring less work due to fewer concurrent releases.

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

Re: Fedora Lifecycles: imagine longer-term possibilities

[John Florian]

I concur. This is effectively what I was trying to express with respect to the 
distinctions. 

On November 14, 2018 12:39:40 PM EST, Kevin Kofler  
wrote:
>Ralf Corsepius wrote:
>> This would be my proposal, also. I would simply extend the release
>> cycles to 1 year and to return to the roots. I.e. make a distro, and
>> drop "rings" "modules" and "spins".
>
>Rings and modules should go away indeed, but spins should not! We have
>had 
>spins since Fedora 7! They are part of the success story of Fedora.
>
>What should be dropped, though, is the artificial distinction between 
>"editions" and "spins". Everything should be an equally-featured spin,
>and 
>the GNOME spin should be called GNOME spin.
>
>Kevin Kofler
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives:
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

Re: Fedora Lifecycles: imagine longer-term possibilities

[John Florian]

On 11/14/18 10:36 AM, mcatanz...@gnome.org wrote:
We need to rebase GNOME within about two months of the new upstream 
releases, or we'll lose our edge with the GNOME community. We'd be 
ceding our position as best GNOME distro to Ubuntu and Arch.


It seems wrong that a DE, even if it's the default, has so much sway 
over the distro as a whole.  I use Fedora for so much more than a 
desktop.  Admittedly, I've never been a big fan of spins and would much 
prefer to see all DEs and other spin-like things just be more rpms I can 
install, if I choose ... all on top of a single base OS.


So a one-year cycle means a major GNOME version update will need to 
land in the middle of a release to avoid that. And these do not have a 
good reputation for stability. Basically we'll wind up with a bunch of 
bugs landing halfway through the release, and without the usual Fedora 
QA process to ensure the most important of them get fixed before they 
reach users.


Why can't GNOME be updated mid-release like any other application?  Why 
does the QA process require the cadence of the whole distro release 
process to bend to GNOME?  Can't a major GNOME update land in the 
testing repos to have QA issues sorted out there just as well as in some 
alpha/beta release of the overall Fedora?


I would think that the distro release cadence only have hard limits set 
by things like the kernel and glibc.  I'm probably taking an entirely 
too simple view of the overall process and am not attacking GNOME 
specifically, but just as an example given your comment.  I'm just 
genuinely trying to understand the reasoning behind it and see if those 
assumptions cannot be changed.


I'd love to see Fedora move to a one year release, but with a 6 month 
upgrade period (N and N-1 for 6 months vs the present N, N-1 and N-2 for 
1 month).  I'd think that would mean less work for maintainers and 
provide nearly the same or better benefit to users as what we have now.

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

Re: Enabling powerline theme system wide by default

[John Florian]

On 11/2/18 9:41 AM, Stephen Gallagher wrote:

On Fri, Nov 2, 2018 at 9:10 AM Dominik 'Rathann' Mierzejewski
 wrote:

On Thursday, 01 November 2018 at 01:13, Luya Tshimbalanga wrote:

It will be nice to enable powerline theme by default system and user
wide. Simple reason is refresh the look of terminal while also providing
useful information especially for git branch. Since powerline does not
impact the performance, it will be great to set for Fedora 30.

Comments welcome.

You could start by explaining what "powerline theme" is and why is
it worth enabling.


https://fedoramagazine.org/add-power-terminal-powerline/
That provides a nice overview, but as someone who's extensively diddled 
their bash configuration to achieve most all of this via a very 
glorified PS1, can anyone tell me why powerline needs a daemon?  Or if 
it's not needed, what benefit does it bring?

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

Re: Fedora should replace mailing lists with Discourse

[John Florian]

On 10/17/18 4:27 PM, Tomasz Torcz wrote:

On Wed, Oct 17, 2018 at 02:54:23PM -0400, John Florian wrote:

With things like reddit or LWN, you get to read it
over and over and over again if you really want to see whats new now.

   https://lwn.net/Comments/unread will show you comments posted
afteryour last visit, with one post in grey to provide context.
Requires subscription, though.


Ha!  All these years later and now I learn this.  Thanks Tomasz for 
sharing that.  And my apologies to Corbet and friends for my lack of 
awareness.


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

Re: Fedora should replace mailing lists with Discourse

[John Florian]

On 2018-10-17 13:41, Gerald B. Cox wrote:
On Wed, Oct 17, 2018 at 10:31 AM Jason L Tibbitts III 
mailto:ti...@math.uh.edu>> wrote:


> "GBC" == Gerald B Cox mailto:gb...@bzb.us>>
writes:

GBC> People keep saying it isn't sufficient or it doesn't work.  I've
GBC> been using it for 3 days and looks and acts like a normal mailing
GBC> list.

And I've been using it since the RT project switched a couple of years
ago.  And... it doesn't really look and act like a normal mailing
list.
Putting aside the issues with formatting of messages which is
discussed
elsewhere in this thread, certainly it generates messages and accepts
replies and so technically it's a mailing list.  But as a medium for
discussion which involves email, it simply doesn't work out.  the
system
appears to either foster or encourage changes which result in the
delivered messages being less useful than messages from a mailing
list.

The fundamental problem is that web forums tend to make less use of
quoting.  The end result is similar to top-posting, but in the other
direction.  Instead of complete "context" that's primarily
useless, the
result is no context at all.  So you have to browse the rest of the
thread in your email program (which thankfully is still possible) or
click over to the web site.  Neither is ideal.

So, really, you've used it for a couple of days, have declared it
fine,
and then boldly declared "Fedora should replace mailing lists with
Discourse".  But I've used it for a bit longer, and my experience has
simply been negative.  The discourse system simply does not serve to
foster email-based discussion.


Yes, I've only used it for a few days - but I disagree with your 
wholesale assumption regarding
context.  There have been countless times when I've started reading a 
topic mid discussion for
various reasons and I have no idea what the original point was.  I 
then either have to trudge through
my mail archives or go to the website and search through the entire 
topic to understand what is going on.


IMO, it's easier to do that with discourse than with the mailing list.


I've never used Discourse other than to do a very quick perusal these 
last few days when this came up.  I am quite familiar with the forum 
model however.  How does Discourse handle posts you've already read in a 
thread that's still active.  With things like reddit or LWN, you get to 
read it over and over and over again if you really want to see whats new 
now.  With my mail client, it's extremely easy and effective to put it 
into threaded mode and highlight the unread (or filter out the already 
read).  With that, I can usually follow along very easily.  Yes, 
sometimes I need to go back in the thread to get context.  But its rare 
that I'll go back to a thread on a forum to find new comments later on 
once I've read many already. That's like watching a movie, getting a 
third of the way through it and realizing you've seen it before.


Now for historical review where a thread is dead, something like 
Discourse would be great due to the cleanliness of not having repeated 
context.  But that's an entirely different use-case and not the primary one.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Packaging Guidelines on docs.fedoraproject.org

[John Florian]

On 2018-10-01 17:04, Björn Persson wrote:

John Florian  wrote:

And conversely, shouldn't
https://fedoraproject.org/wiki/Packaging:Guidelines be telling viewers
they now need to go to docs.fp.o?

Not until the conversion is finished, in my opinion.

I would agree with that, but I read the announcement as if this *was* 
finished.  It said "moved" so that was my impression, but I see with the 
discussion here that maybe this is really more like an RC?

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

Re: Fedora Packaging Guidelines on docs.fedoraproject.org

[John Florian]

On 2018-10-01 10:51, Zbigniew Jędrzejewski-Szmek wrote:

I think we instead should make sure that all docs under docs.fp.o
contain good links to those pages on the wiki.


And conversely, shouldn't 
https://fedoraproject.org/wiki/Packaging:Guidelines be telling viewers 
they now need to go to docs.fp.o?

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

Re: Orphaning clementine

[John Florian]

On 2018-09-05 14:22, John Florian wrote:
I also prefer my "random" music pre-shuffled so I can see what's 
coming up and what's behind me.  (I honestly own so much music 
sometimes I don't know who just played.)


And now that I've posted that, I see there's Edit/Randomize List vs. 
Playback/Shuffle.  Sweet.

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

Re: Orphaning clementine

[John Florian]

On 2018-09-05 13:41, Gerald B. Cox wrote:
I would recommend you check out qmmp.  It's light weight, runs with 
qt5 and does what it sets out to do, which is be a flexible, 
lightweight music player that runs on qt5, supports skins, has many 
good plugins for extra features, supports tagged and folder based 
album covers, etc.


There is a thread here: bit.ly/2M2JgnE - where players are discussed.

qmmp has been has been actively maintained since it first come out in 
2007.


The current release is 1.2.3 which was released July 20th, 2018.


That's good to know, thanks!  It does look like it could do the job for 
me.  I hope to continue to use clementine, if possible but qmmp looks 
quite solid for the basics -- at least once I got rid of that dreaded 
default interface.  Count me in the same category as Rex Dieter of 
finding it way too small and I don't know I would have found the setting 
buried in the plugins had you not pointed it out in that thread.  I do 
have to say, I like the plugin nature though. Kind of reminds of the old 
firefox that was pure and small; add only the bloat you need.  I haven't 
tried to do any tag editing with it yet, but it appears to be there.  My 
biggest miss would be dynamic playlists where I could create some pretty 
crazy schemes for what I wanted to hear (or not hear).  I also prefer my 
"random" music pre-shuffled so I can see what's coming up and what's 
behind me.  (I honestly own so much music sometimes I don't know who 
just played.)


But qmmp certainly is the most solid alternative I've seen.  I tried 
deadbeef and juk and found them lacking too severely.  I might no't have 
tried qmmp had you not given me reason to give it a 2nd look since I had 
never been fond of the ol' xmmp days.  I'm too old, tired and 
cantankerous to have UIs that don't follow basic conventions unless 
there's extremely good reasons to do so (e.g., qcad).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning clementine

[John Florian]

Jan, as a longtime clementine user, I'm sorry to read this.  I had no 
idea upstream had gone dormant.  It works great for me, but I have no 
idea of what pain may have been involved in getting/keeping it in that 
form for users like me.  Unfortunately, I too am short on time (and I 
don't do C).  Thanks for all you've done!


Do you know of a good alternative, preferably Qt-based, KDE/Plasma 
friendly, and available in Fedora?



On 2018-09-05 07:05, Jan Grulich wrote:

Hi,

I haven't been using clementine for a long time and don't have really time
looking into clementine issues. This is even more complicated given upstream
is more or less dead and latest release is more than 2 years old.

Feel free to take it.

Regards,
Jan

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

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

Re: Fwd: [RELEASED] Python 3.4.9 and Python 3.5.6 are now available

[John Florian]

On 2018-08-09 08:23, Miro Hrončok wrote:

On 8.8.2018 17:43, John Florian wrote:

On 2018-08-08 10:47, Jason Tibbitts wrote:

"JF" == John Florian  writes:

JF> How difficult would it be to provide modern Python (e.g. 35 or 36)
JF> in EPEL?

Obviously not that difficult, since it is already there.

By that I assume you mean 34, right?  Or am I overlooking something?


You are overlooking the pythno36 package.



I sure am.  Thanks for pointing that out.  Now I'm off to check what's 
wrong with my brain.

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

Re: Fwd: [RELEASED] Python 3.4.9 and Python 3.5.6 are now available

[John Florian]

On 2018-08-08 10:47, Jason Tibbitts wrote:

"JF" == John Florian  writes:

JF> How difficult would it be to provide modern Python (e.g. 35 or 36)
JF> in EPEL?

Obviously not that difficult, since it is already there.

By that I assume you mean 34, right?  Or am I overlooking something?

   The main
problem is that the way it was done requires that Fedora specfiles grow
additional complication in order to be built in EPEL, so it isn't just a
matter of rebuilding a bunch of existing packages.
IIRC, the Software Collection stuff has newer ones that I could use, but 
all the install/setup stuff is cumbersome as compared to declaring a few 
simple deps in my spec files.  If you or anyone has references how to 
pull SC deps in neatly, I'd love to see that.


I suppose I'm just in the same boat everyone else is where the life of 
Fedora releases are too short to be ideal for production environments 
and EL releases are just too old.  Of course, if the Fedora releases 
lived longer, they also would be(come) too old.  It just seems EPEL 
never quite lives up to what it ideally could be, the latest offerings 
from Fedora atop EL.

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

Re: F29 System Wide Change: Make BootLoaderSpec the default

[John Florian]

On 2018-06-18 12:39, Chris Murphy wrote:

kdump is
enabled by default on RHEL (and maybe CentOS, not sure).


I can confirm it is on CentOS.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3PHPCFLKLLC2GVHZV6CXXJLGIOLPG4L3/

Re: FESCo Elections - May 2018 : Results announcement

[John Florian]

On 2018-06-14 09:27, Brian (bex) Exelbierd wrote:



On Thu, Jun 14, 2018 at 3:02 PM, Michael Cronenworth > wrote:


On 06/14/2018 03:42 AM, Pierre-Yves Chibon wrote:

I know we never manage to motivate many people to vote, but 86
votes is really
low, even for us:(


Yes, I was checking out the voter count on other pollings and the
turnout is around 100. Disappointing. :(

Lack of awareness or advertising? I voted.


I've heard from several people (warning anecdata!) that they often 
don't vote when they are happy with the way things are.  One person 
specifically said they didn't vote because they liked the whole slate 
of candidates and were ok with whomever won.


This was the first time I've ever voted despite using Fedora from the 
beginning (well, RH 4.0 days actually).  Anyway, much of what's been 
said here holds true for me.  Why did I vote this time?  It certainly 
wasn't because I hoped for a change, rather it was just me trying to 
increase my involvement.  Oddly enough, after reading the Q of each 
contender I realized my proper vote would effectively be a no-op.


So the universe is telling me that my vote on FESCo could have a 
significant impact, yet I'm happy regardless of the outcome. Meanwhile, 
my vote for US elections has almost zero impact, yet I can't be happy 
with the outcome.  Why does it feel like Douglas Adams is behind all of 
this?  :-)




We can debate if this is good or bad, but it does mean that low turn 
out is not automatically bad.


I agree.  I don't see this as bad.  In fact, I might argue that it is 
most definitely good.  Therefore, in that spirit, congrats to all, 
winners and "losers".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/57ZICFRBQCUUM64YEVVNMWW36EL4CVPZ/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[John Florian]

On 06/08/2018 04:07 AM, Tomas Mraz wrote:
> On Thu, 2018-06-07 at 16:13 -0400, John Florian wrote:
>> On 06/07/2018 08:44 AM, Tomas Mraz wrote:
>>> On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
>>>> On 06/05/2018 12:25 PM, Tomas Mraz wrote:
>>>>> On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
>>>>>> "Fallback option" always smells like "protocol downgrade
>>>>>> attack".
>>>>>> This would undermine the idea of a crypto policy. Anyway,
>>>>>> implementing it seems way out of scope for the crypto policy.
>>>>> Yes, a fallback option is a no-way. You can switch the system
>>>>> policy to
>>>>> LEGACY, however that does not necessarily mean that some very
>>>>> old
>>>>> legacy HW will start to work with Firefox or another web
>>>>> browser,
>>>>> because with newer versions of the browsers and newer versions
>>>>> of
>>>>> TLS/crypto libraries some very old and insecure algorithm and
>>>>> protocol
>>>>> support is being also removed.
>>>>>
>>>> Makes sense, but what is the best way to deal with such old HW if
>>>> you're
>>>> stuck with it?  I don't want to compromise my workstation for all
>>>> my
>>>> normal needs just to deal with some ancient embedded https
>>>> server,
>>>> but
>>>> it would kind of suck to have to boot some old live image just to
>>>> do
>>>> some routine config change.  It seems the industry has room for
>>>> improvement here.
>>> Use a virtual machine with some old live image for such insecure
>>> communication?
>>>
>>> I do not think any "improvement" that involves changing the
>>> defaults to
>>> be more lenient even if accompanied with some big warning when such
>>> old
>>> insecure connection is established would be a good idea. Оnly if
>>> the
>>> users really have to boot some old live image or do some similar
>>> unpleasant task it will really force the old HW out of production
>>> where
>>> it should belong. Or we can forget about security based on
>>> cryptographic protocols altogether.
>>>
>>> Note that we are talking about SSLv2, MD4 or similar long long time
>>> ago
>>> obsolete stuff. Not things that were just "recently" found as
>>> insecure.
>> Oh!  I didn't realize the proposal was covering stuff /that/ old. 
>> Somehow TLS 1.1 just didn't equate in my memory with that era. Thank
>> you 
>> Tomas for the clarification.
> No, this is misunderstanding. The change proposal is about newer stuff
> but the proposal allows for easy revert by setting the crypto policy to
> LEGACY.
>
> What I was talking in this tread starting with my message from Tue, 05
> Jun 2018 18:25:57 +0200 was about things that possible very old legacy
> devices might require for communication that are not present in the TLS
> libraries anymore.
>
Okay, so IIUC now, this is an all-or-nothing kind of change.  If I
elect/need to use LEGACY to administer some old hardware that I cannot
otherwise connect to using the defaults, then I'm compromising that
host's security for anything/everything its used for until it's taken
back off LEGACY and returned to whatever the non-LEGACY is called.  Do I
have it right now?

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

Re: F29 System Wide Change: Strong crypto settings: phase 2

[John Florian]

On 06/07/2018 08:44 AM, Tomas Mraz wrote:

On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:

On 06/05/2018 12:25 PM, Tomas Mraz wrote:

On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:

"Fallback option" always smells like "protocol downgrade attack".
This would undermine the idea of a crypto policy. Anyway,
implementing it seems way out of scope for the crypto policy.

Yes, a fallback option is a no-way. You can switch the system
policy to
LEGACY, however that does not necessarily mean that some very old
legacy HW will start to work with Firefox or another web browser,
because with newer versions of the browsers and newer versions of
TLS/crypto libraries some very old and insecure algorithm and
protocol
support is being also removed.


Makes sense, but what is the best way to deal with such old HW if
you're
stuck with it?  I don't want to compromise my workstation for all my
normal needs just to deal with some ancient embedded https server,
but
it would kind of suck to have to boot some old live image just to do
some routine config change.  It seems the industry has room for
improvement here.

Use a virtual machine with some old live image for such insecure
communication?

I do not think any "improvement" that involves changing the defaults to
be more lenient even if accompanied with some big warning when such old
insecure connection is established would be a good idea. Оnly if the
users really have to boot some old live image or do some similar
unpleasant task it will really force the old HW out of production where
it should belong. Or we can forget about security based on
cryptographic protocols altogether.

Note that we are talking about SSLv2, MD4 or similar long long time ago
obsolete stuff. Not things that were just "recently" found as insecure.


Oh!  I didn't realize the proposal was covering stuff /that/ old. 
Somehow TLS 1.1 just didn't equate in my memory with that era. Thank you 
Tomas for the clarification.


Also, I just found this neat[0] table that seems to present a good 
high-level view of the various TLS levels.


[0] https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5BEYIJLDWIHXQVTUZRQ6AN3RKASFOP2Z/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[John Florian]

On 06/06/2018 08:05 AM, Petr Pisar wrote:

On 2018-06-05, John Florian  wrote:

Makes sense, but what is the best way to deal with such old HW if you're
stuck with it?  I don't want to compromise my workstation for all my
normal needs just to deal with some ancient embedded https server, but
it would kind of suck to have to boot some old live image just to do
some routine config change.  It seems the industry has room for
improvement here.

Firefox has a white list for domain names: security.tls.insecure_fallback_hosts.
Okay, that's good to know.  As long as that continues to work should 
this proposal go in effect that seems like a great compromise of having 
sound security by default but allowing manual, per-site overrides where 
necessary.

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

Re: F29 System Wide Change: Strong crypto settings: phase 2

[John Florian]

On 06/05/2018 12:25 PM, Tomas Mraz wrote:

On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:

"Fallback option" always smells like "protocol downgrade attack".
This would undermine the idea of a crypto policy. Anyway,
implementing it seems way out of scope for the crypto policy.

Yes, a fallback option is a no-way. You can switch the system policy to
LEGACY, however that does not necessarily mean that some very old
legacy HW will start to work with Firefox or another web browser,
because with newer versions of the browsers and newer versions of
TLS/crypto libraries some very old and insecure algorithm and protocol
support is being also removed.



Makes sense, but what is the best way to deal with such old HW if you're 
stuck with it?  I don't want to compromise my workstation for all my 
normal needs just to deal with some ancient embedded https server, but 
it would kind of suck to have to boot some old live image just to do 
some routine config change.  It seems the industry has room for 
improvement here.

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

Re: F29 System Wide Change: Strong crypto settings: phase 2

[John Florian]

On 06/05/2018 12:55 PM, Chris Murphy wrote:

I don't understand the motivation of departing from upstreams, which
by their nature are on a knife's edge balancing security and practical
use in the real world. Why second guess that effort and on what basis?

Totally agree!

Slightly off topic as an anecdote, but the Payment Card Industry Data
Security Standard (PCI DSS) is only calling for the end to TLS 1.0
support at the end of this month, recommending TLS 1.2 but permitting
TLS 1.1. This is the spec for transmitting people's credit card
magnetic stripe/chip information for payment authorizations. Now maybe
that's a bit eyebrow raising, but if they're willing to take the risk
of allowing TLS 1.1 for such a use case, I hardly think Fedora should
be jumping the gun.
That's why there's transaction fees.  Oops!  Oh well, here's a few 
million to deal with that.  They advertise like they can't get rid of 
the money fast enough.  I always figured the Visa "Magic Moments" were 
something like hot database redirection where some transactions fell off 
the end of the cable, landed on the floor and turned into customer's 
lucky day simply due to the timing.  Like it was easier/cheaper to give 
away the fruits rather than fix the real problem.


I doubt it's actually like that, but I do bet they have more luxury than 
Fedora does.  While I'd prefer the best security, I don't want it at the 
risk of things being broken.  I don't have the confidence that my work 
around is as safe as an older more trusting Fedora. When I see those 
cipher suite strings my head just goes into a tailspin.

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

Re: Release criteria proposal: drop kickstart package criterion

[John Florian]

On 06/05/2018 07:59 AM, Stephen Gallagher wrote:



On Tue, Jun 5, 2018 at 7:13 AM Josh Boyer > wrote:


On Tue, Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
mailto:zbys...@in.waw.pl>> wrote:
>
> On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote:
> > On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
> > mailto:adamw...@fedoraproject.org>> wrote:
> > > Hi, folks!
> > >
> > > We currently have a Final release criterion that reads as
follows:
> > >
> > > "A spin-kickstarts package which contains the exact
kickstart files
> > > used to build the release must be present in the release
repository.
> > > The included kickstarts must define the correct set of release
> > > repositories.
> > >
> > > Why?
> > >
> > > This is considered part of Fedora's duty to be
'self-hosting': the
> > > kickstarts used to produce the release images are a vital
piece of
> > > information required to duplicate that release, so they must be
> > > preserved along with the release."
> > >
> > > Lately this requirement has been fairly annoying in
practice. Updating
> > > the package prior to release does not appear to be in
anyone's regular
> > > schedule, so invariably what happens is shortly before the
release
> > > deadline I realize we haven't built a 'release'
spin-kickstarts package
> > > and have to file a blocker bug and ping people with the
necessary
> > > permissions (of which there are only a few) to build one in
a tearing
> > > hurry. Then we have to approve the blocker bug and push the
updated
> > > package through the freeze, all wasting time we could be
spending on
> > > more important fixes.
> > >
> > > The benefit here is really fairly tiny, as well. It's
arguable whether
> > > anyone cares particularly whether a Fedora release, as a frozen
> > > artifact, is 100% internally reproducible (and I'm not sure
whether our
> > > releases actually *are* reproducible in any case, these
days, I'm not
> > > at all sure we ship all the necessary metadata and so on for
*every
> > > single deliverable* within the distribution).
> > >
> > > These days I'd suggest it should be quite acceptable to
simply use git
> > > tags for this purpose. It should be quite easy for rel-eng
to adjust
> > > the release scripts to create a tag in the fedora-kickstarts
repo (and
> > > why not fedora-comps too, while we're at it) for each
'candidate'
> > > compose, named for the compose ID. That would make it very
easy to
> > > access the correct kickstarts for any Fedora candidate
compose just by
> > > a 'git checkout', with no need for the cumbersome work of
getting the
> > > package into the compose.
> > >
> > > Naturally this would go along with updates to any relevant
docs or wiki
> > > pages, recommending to use the git repository instead of the RPM
> > > packages, and explaining the tagging scheme. As for the
package, we
> > > could either keep it but not sweat about updating it for
each release,
> > > retire it entirely, or change it to contain only a text file
pointing
> > > to the git repository (or to the doc / wiki page that
explains the git
> > > repo location and tagging strategy).
> > >
> > > Thoughts? Thanks!
> >
> > It makes perfect sense, the package is not actually shipped as
part of
> > any of the actual deliverable artifacts and they're widely
available
> > in a public git repository for people to consume so it's not
reducing
> > the ability to reproduce Fedora, we don't rush around and
ensure all
> > the tools that might need last minute patches in the compose
process
> > are all tagged stable in the release either so I don't see
actually
> > shipping this package as stable makes any difference in
reality, we
> > don't even use the package in the compose process, we pull the
> > kickstarts directly from git.
>
> +1 too.

Yes, let's do what makes sense.  I like the proposal.


And my axe! Err, or my +1, yeah.


Ditto!  I've referenced these a number of times to see where my variants 
have gone astray, but have always used the git repo for this and hadn't 
even thought of looking for such an artifact.  The proposal of tags and 
docs will only make this easier.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: Hiding the grub menu by default on single OS installs

[John Florian]

On 06/01/2018 12:10 PM, Rex Dieter wrote:
> Michael Watters wrote:
>
>> What about users that don't use a graphical login manager?  Personally I
>> *like* seeing boot messages so that I know what is going on.
>>
>> Having the menu available is also quite useful for booting into rescue
>> mode or selecting a different kernel.
> Note, this is all about defaults.  If *you* like something, you can always 
> modify the configuration to bring it back.

That still overlooks my chief concern here... what if you need the
classic behavior during an install attempt?  Are we going to be forced
to produce custom live images just so we can see what the hell is going
wrong?  I love that a can make Fedora my Fedora, but this sounds like a
proposal to drive me away the first time I'm bitten by it.

Also, I'm entirely unclear on the scope.  Is the affecting Fedora
Workstation (GNOME) only or all spins?  The proposal says Workstation
but it doesn't explicitly exempt the others, unless I missed something. 
If it's confined to the Workstation/GNOME install, I'm unaffected
because that spin already has removed so much choice that I'll never
consider it again.

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

Re: Hiding the grub menu by default on single OS installs

[John Florian]

On 06/01/2018 03:07 PM, DJ Delorie wrote:
> Hans de Goede  writes:
>> 1) . . ., no way to get to the menu
> I think this steps over a line we should not cross.
>
> There's a huge difference between HIDING grub's functionality, and
> essentially DISABLING it.  While I'm opposted to hiding the grub menu in
> general, as long as there's some obvious way to access it, it's only a
> small annoyance.
>
> But I boot rarely, and when I do, it's usually because something has
> gone horribly wrong and I need as much control over the boot process as
> possible to get the system running again.  Making it difficult for me to
> even find the tools I need only makes a bad day worse.  And the benefit
> of a few seconds of boot time is no benefit at all for me.
>
> And don't say "well you can change it if you want to" if my use case
> represents a significant portion of Fedora users.  Do we even know how
> many users will end up changing it?  Or would prefer it available?  Vs
> how many users really need that extra 1-2 seconds of boot time
> reduction?
>
> And don't say "it will show a menu when it thinks you need it" because
> that's just plain hubris.  I can pretty much guarantee that its idea of
> when *I* need it, does not match *my* idea.
>
> Perhaps boot time is a concern for some Fedora users, like laptops (why
> aren't they just sleeping?) or VMs/containers (kickstart can change the
> defaults anyway), but for others it's an impedement (servers, desktops).
> Let's not go so far to please one group of users that we aggravate
> (or even alienate) another.

Well said.  I really wish Fedora had a way of polling its user base
democratically for such polarizing changes BEFORE imposing them.  Such
feedback ideally would be built into and deployed as part of the OS and
not require users to routinely go check if their opinion is needed. 
Rather some client software would do this periodically and then request
the user participate.

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

Re: F29 System Wide Change: Hide the grub menu

[John Florian]

On 05/31/2018 03:36 PM, Jason L Tibbitts III wrote:

what we should be going for is a
completely smooth transition between the BIOS logo and the login screen,
with no flashing back to text mode.
Should we? Yes, I get that looks nice, but it can be at the cost of 
functionality.  In the end, I sit in front of computer to do work, not 
be entertained by pretty things, especially the lowly boot process.  
That's like bragging about how cool the spark plugs look in your new car.

   I am pretty sure that's the end
goal here and hiding the grub menu by default is just a step in that
direction.
I'm sure it is.  That's the unfortunate, inexorable trend.  And I'd be 
totally okay with this ... if only I never had the problems that make 
these changes more painful.  Unfortunately, those problems are just as 
frequent as ever (and likely always will be when running against such 
diverse hardware) but the barrier to resolve them keeps getting more 
challenging.  That's a terrible trade-off IMHO for what amounts to 
nothing than aesthetics.  Apple can get away with this because the own 
platform top to bottom.  We don't have that luxury.

if they want, revert) a changed default
Again, this only applies to a system that once worked where you can make 
that change.  When fighting a borked system where the install fails this 
isn't an option.

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

Re: F29 System Wide Change: Hide the grub menu

[John Florian]

On 05/31/2018 06:43 AM, Jan Kurik wrote:

= Proposed System Wide Change: Hide the grub menu =
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu


Owner(s):
   * Hans de Goede 


On systems with only a single OS installed, the grub menu does not
offer any useful functionality, so we should hide it by default.


I really dislike these kind of changes.  Does Fedora really have that 
large of non-technical audience?  I'm perfectly capable of undoing this 
on a normal install that I use.  I still prefer the plymouth-details 
theme for example.  I also add more grub time to allow me time to react 
(and my slow USB keyboard to become ready) -- if I have to wait several 
minutes for a POST, shaving a second or two only to miss a prompt just 
plain sucks.  I really don't see the value in hiding so many things that 
might be useful when crap hits the fan.


I'm particularly grumpy right now after sitting under said fan as I 
spent over 2 weeks trying to get F28 installed on a new very nice Dell 
Precision 5820 workstation with dual 256GB NVMe drives that has defied 
all reasonable logic.  Same ISO (KDE live) put on CFast via USB installs 
fine, never succeeds in booting vs. ancient spinning photons works 
nearly every time.  Why 2 weeks?  Oh, just trying every reasonable (and 
eventually the unreasonable) choice in the BIOS and kernel cmd-line 
options.  Normally Fedora is quite smooth, but 28 plus this particular 
hardware proved a nightmare.  I continued torturing myself even after I 
had success in hopes of making a decent bug report, but, as mentioned, 
it defied all logic. And all that time, these kind of "hide the geeky 
stuff" did nothing but hinder my efforts.


If we really must go down this road further, it be nice to see it done 
in a more dynamic way.  E.g., booting the same kernel and initramfs as 
the last time and that worked so this time we can be "pretty" and 
"faster".  Something changed or this is a new install? Let's be a little 
more verbose and helpful until it's known good.

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

Re: Heads up: selinux-policy-3.14.1-25.fc28 breaks GDM

[John Florian]

On 2018-05-24 10:09, Jerry James wrote:
The problem may be restricted to systems using the Nvidia proprietary 
driver.


I have that driver and was also affected, though am using sddm rather 
than gdm.  My work around was the following local policy:


~~~
module local_sddm 1.0;

require {
    type xdm_t;
    type xserver_misc_device_t;
    class chr_file map;
}

#= xdm_t ==
allow xdm_t xserver_misc_device_t:chr_file map;
~~~
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P2MVSNB5YSBSHGPP367TG6M5FAP33AUJ/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[John Florian]

On 2018-05-04 12:25, Przemek Klosowski wrote:

On 05/04/2018 09:42 AM, John Florian wrote:


On 2018-05-04 09:33, Stephen John Smoogen wrote:

I would do so for the following reasons:
1. Even though the security arguments are weak, they are going to be
checkmarks on audits which can't be changed for years.
2. When someone gets a "remove this and find out why the OS did this"
it helps if they can point to an "official" change versus an email.


This is an excellent point.  Chasing the history of such changes 
through myriad email is always frustrating, especially since it's 
often inconclusive of what actually did happen.


Just checking my own PATH, I see some surprising things at the front:

$  echo $PATH
/usr/libexec/python3-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin 



I love Sphinx and Qt, but what are they doing there ... at the 
front?  If nothing else, that seems an inefficient search order. 
Yeah, caching will alleviate most of that, so why are they there at all?
Yeah, I don't like it either. Even if there are reasons for those two, 
it's a bad precedent---if every package did that, $PATH would become 
unmanageable, and impossible to audit.  Furthermore, the way these two 
insert stuff into my $PATH is quirky/hacky: they drop files into 
/etc/profile.d that cover csh and sh


  * python-sphinx  runs 'module load python-sphinx' from
/usr/share/modulefiles/python-sphinx/python2-sphinx which does
'prepend-path'
  * qt just executes  a shell script that manipulates $QT* and $PATH

Since the main reason to mess with $PATH ordering is to override 
same-named commands, I think we should have a guideline that packages 
do not mess with path, or at least don't prepend to it.




Such a guideline makes sense, if there's not already one.  This 
definitely violates the principle of least surprise.  If someone is 
using an alternative shell or they force set PATH rather than modifying 
it, that could lead to abnormal behavior that doesn't help anyone.  I 
really appreciate that rpm won't let us overwrite files of another 
package, but ought there be protection (probably not via rpm) against 
displacing executables due to PATH hackery too? Wouldn't same-named 
commands be better dealt with via the alternatives system?


BTW, on my system, ktechlab also messes with $PATH but at least it 
_appends_ /usr/libexec/sdcc to it. Still, I think sdcc should just go 
to /bin...




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


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

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[John Florian]

On 2018-05-04 09:33, Stephen John Smoogen wrote:

I would do so for the following reasons:
1. Even though the security arguments are weak, they are going to be
checkmarks on audits which can't be changed for years.
2. When someone gets a "remove this and find out why the OS did this"
it helps if they can point to an "official" change versus an email.


This is an excellent point.  Chasing the history of such changes through 
myriad email is always frustrating, especially since it's often 
inconclusive of what actually did happen.


Just checking my own PATH, I see some surprising things at the front:

$  echo $PATH
/usr/libexec/python3-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin

I love Sphinx and Qt, but what are they doing there ... at the front?  
If nothing else, that seems an inefficient search order. Yeah, caching 
will alleviate most of that, so why are they there at all?

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

Re: Fedora 28 Final status is GO

[John Florian]

On 2018-04-26 16:02, Adam Williamson wrote:

FC1 is the trickiest. I don't think any FC1 development schedule was
ever really made public. So for that one I got creative. There's an
article on LWN - written by Joe Brockmeier no less! - around the time
of the release:

https://lwn.net/Articles/56036/

It was written on Wednesday 2018-10-29, and states in part:

"With the first stable release of the Fedora Core scheduled for early
next week..."

Now, the release actually happened on 2018-11-05. Which *is* 'next

s/2018/2003/ from what I can see.  Fingers on auto-fill?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: script to run after hotspot authentication?

[John Florian]

On 2018-04-26 11:36, Paul Wouters wrote:

On Tue, 24 Apr 2018, Sam Varshavchik wrote:


Is there a way to run a custom command after hotspot authentication?



You might be able to hook into dhclient.


That happens when you obtain an IP address. There is no notification
method that I know about that will signal me when the hotspot
authentication has happened. 


What about the NM hoooks[0]?  I've been playing with them recently and 
you get all sorts of events prior to actually gaining a lease.


[0] https://developer.gnome.org/NetworkManager/stable/NetworkManager.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[John Florian]

On 2018-04-17 16:31, Zbigniew Jędrzejewski-Szmek wrote:

My initial example with gpm
is actually good here: do "sudo dnf install -y gpm", move mouse, voilà.


 unless your a lefty ;-)

OT: Why is why I wish sddm was handedness-agnostic.  It's too simple to 
need anything more than click awareness, the type of click shouldn't 
ever matter.

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

Re: Orphaned Packages looking for a new point of contact

[John Florian]

On Fri, 2018-02-16 at 16:40 -0500, David Cantrell wrote:
> On 02/16/2018 11:32 AM, Kevin Fenzi wrote:
> > Greetings.
> > 
> > There's some packages that have been orphaned by FESCo and are
> > seeking a
> > new point of contact to stay in the collection.
> > 
> > If you are interested in becoming the point of contact for these,
> > please
> > note it in the appropriate ticket below for quickest processing.
> > (no need to reopen the ticket, just add your fas name and what
> > packages
> > you want to take)
> > 
> > https://pagure.io/fesco/issue/1839
> > 
> > rpms/clamz
> > rpms/inkboy-fonts
> 
> I'll take clamz

Is clamz even useful anymore?  To the best of my knowledge Amazon took
that option away.  Nowadays, I've been forced to download a zip file if
I wanted to download multiple songs.  I think it's been this way for
several years now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[John Florian]

On Tue, 2018-02-13 at 12:07 -0800, Adam Williamson wrote:
> On Mon, 2018-02-12 at 11:59 -0500, David Cantrell wrote:
> > The dist-git changelogs are mostly noise and I would prefer better
> > organized information about impacts to users and developers.  Like
> > tell
> > me what things changed in the new glibc package, not that the glibc
> > RPM
> > has been upgraded to the new release.  I can figure out that part
> > myself.
> 
> As an alternative perspective on this, I am *constantly* frustrated
> by
> the lack of detail in SCM commit messages, and would much prefer far
> more of it. I frequently find myself wanting to know exactly why
> someone did something seven years ago, and find it entirely
> impossible
> to answer the question from the information available.


Yes!  As a lifelong developer and user with the gray hair of "been
there, done that" I couldn't agree more with this sentiment.  SCM
messages are for developers, not users.  I want an SCM message to
briefly summary WHAT happened and then in detail WHY it happened.  The
changed code itself gives details of WHAT and if it's unclear it ought
have comments in the code, not the SCM message.  Users, on the other
hand, likely don't care about any of that, unless they too are a
developer.  Fine, they don't need anything else.  Plain, non-developer
users however, need to know HOW this impacts them and might appreciate
the WHY.

Beyond that, I really don't care how we get there.  But IMHO, that
should be the goal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[John Florian]

On Tue, 2018-02-13 at 15:33 -0500, Josh Boyer wrote:
> 
> The point is, we have LOTS of places where change information or
> discussion occurs.  We should try and have a canonical location for
> the *descriptive summary* of these changes/discussions.

This hit home.  Way back in the early 90s when I was new to Linux this
was one of the more frustrating things for me.  Mastering RHL (later
Fedora) was an exercise in knowing *where* to look and you can't even
know to look there until you become aware that there's yet one more
source.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Rename "nobody" user

[John Florian]

On Thu, 2018-01-11 at 10:08 -0800, Adam Williamson wrote:
> On Thu, 2018-01-11 at 10:19 -0700, Chris Murphy wrote:
> > "Upgrading the system multiple times through the upgrade process
> > should give a result that is the same as an original install of
> > Fedora
> > Workstation."
> > https://fedoraproject.org/wiki/Workstation/Workstation_PRD
> 
> 

> We should probably rephrase it (and the release criterion, which IIRC
> says something similar) to be more realistic, though I admit I can't
> come up with a great idea right now.

Should this at least be s/as an original/as the original/?  IOW, does
this mean the upgrade preserves as if no upgrade has occurred or does
it mean the upgrade behaves as if a new install?  I suspect the former,
but it's less than clear to me, regardless of whether we achieve it or
not.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability

[John Florian]

On 01/03/2018 06:02 PM, Adam Williamson wrote:

> * The most useful feedback is just whether the kernel boots and works
> correctly on all systems you have access to (assuming they worked OK
> with the previous kernel, of course). If it does, please leave positive
> karma on the relevant update.


I know this update is already out of testing but I wanted to share my
feedback nonetheless as I ran into some regressions.  My x86_64 box
looked to be hanging during boot.  My first thought was, yeah got to run
`akmods --force && reboot` as I always seem to have to for the stupid
nvidia drivers.  (I'd much prefer nouveau but have had no end of
stability problems.)  However, I couldn't get my usual console on tty2
... or anywhere.  Tried rebooting in single user mode and got the same
result.  Today I tried adding `nopti` ... no discernible difference.
Finally, I just let it hang, went to another box and found I could ssh
in.  Wasn't hung at all, but it was the usual nvidia driver problem.

So, the big Qs are:

Why couldn't I get a login on tty2?
Why didn't single-user work?

Oddly, both work now that the kmod has been rebuilt.

Other details:
Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
Gigabyte Z97X-UD3H-BK-CF
kernel-4.14.11-300.fc27.x86_64

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

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[John Florian]

On Fri, 2018-01-05 at 16:02 +0100, Pavel Březina wrote:
> On 01/05/2018 03:14 PM, John Florian wrote:
> > On Fri, 2018-01-05 at 14:50 +0100, Jan Kurik wrote:
> > > The tool is packaged with a default
> > > profile set that is fully supported. If an administrator has
> > > different
> > > needs they can create a custom profile and make it accessible in
> > > authselect by dropping it in the tool specific directory.
> > 
> > How?  The authselect(8) man page tells me that `authselect show
> > profile_id` will print info about the profile, but I see nothing of
> > any
> > detail.  (Perhaps more could be gleaned with `--trace`, but without
> > any
> > apparent dry-run option I'd want a VM to experiment.)
> 
> There is also authselect-profiles(5) that explains how profiles
> works. 
> But it is not yet present in current Fedora packages. I will do new 
> release on Monday.

Ah, that explains a lot.  I did fail to mention this was all from the
perspective of a F27 system.


> > Looking at the package contents doesn't help much either:
> > 
> > $ rpm -ql authselect
> > /usr/bin/authselect
> > /usr/lib/.build-id
> > /usr/lib/.build-id/b6
> > /usr/lib/.build-id/b6/6bcffc0719e16ebb39e888f8da173aa2bd464e
> > /usr/share/man/man8/authselect.8.gz
> > 
> > So the built-in profiles are hard-coded into the binary?  I might
> > have
> > expected a data dir providing these to serve as examples for making
> > new
> > ones.
> 
> Yes, there is a data dir: /usr/share/authselect/

Doh!  I see now that's part of authselect-libs, a package I failed to
notice getting installed alongside of authselect itself.

> Description of these directories may be seen in the man page,
> currently 
> at this upstream link:
> https://github.com/pbrezina/authselect/blob/master/src/man/authselect
> -profiles.5.txt.in.in

Oh, very nice!

> > I also didn't see (nor did I even try searching for) any mention of
> > the
> > upstream project.
> > 
> > Otherwise, this is a very nice write up.  I'm mostly curious as our
> > setup uses an openldap directory server for identity and WinAD for
> > authentication.  realmd doesn't seem to cover (from a very cursory
> > glance) that arrangement.  So I have an eye out for how to best
> > leverage these things, if at all.
> 
> We had many discussions on this topic while designing and developing 
> authselect. The resolution was to include only sssd and winbind
> profiles 
> and avoid other use cases and avoid plain ldap and kerberos since
> they 
> can be implemented with sssd. So the use case that you have
> mentioned 
> above (different id and auth providers) can be achieved.

That makes sense and seems like a wise choice.


One last thought, how friendly is this going to be with tools like
puppet and ansible?  For example, would something like this be doable?

exec { 'authselect select sssd':
  unless => "authselect current | grep -q '^sssd$' && authselect check
| grep -q unmodified"
}

The idea being to only run to make a change if needed to keep change
reports tidy.  I can't quite tell at this point because:

$ sudo authselect current
No existing configuration detected.

In this sense, it would be helpful if authselect(8) had some details
about exit codes.  Also, the "check" command could be more explicit
about what happens with exit codes/output messages when:
  * the config was created by authselect and remains unmodified
  * the config was created by authselect but has since been modified
  * the config hasn't apparently ever been touched by authselect

Maybe another command like "test" command could be ideal for the job if
it did much the same but gave diff output and suitable exit code
indicating spot-on vs. needs-change.

I ask because I'd far prefer to have a well maintained tool like
authselect managing PAM versus self-hacked file replacements based on
old configurations that once may have been correct(ish).  PAM syntax is
a wee bit too arcane and yet immensely critical to go mucking around
haphazardly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[John Florian]

On Fri, 2018-01-05 at 14:50 +0100, Jan Kurik wrote:
> The tool is packaged with a default
> profile set that is fully supported. If an administrator has
> different
> needs they can create a custom profile and make it accessible in
> authselect by dropping it in the tool specific directory.

How?  The authselect(8) man page tells me that `authselect show
profile_id` will print info about the profile, but I see nothing of any
detail.  (Perhaps more could be gleaned with `--trace`, but without any
apparent dry-run option I'd want a VM to experiment.)

Looking at the package contents doesn't help much either:

$ rpm -ql authselect
/usr/bin/authselect
/usr/lib/.build-id
/usr/lib/.build-id/b6
/usr/lib/.build-id/b6/6bcffc0719e16ebb39e888f8da173aa2bd464e
/usr/share/man/man8/authselect.8.gz

So the built-in profiles are hard-coded into the binary?  I might have
expected a data dir providing these to serve as examples for making new
ones.

I also didn't see (nor did I even try searching for) any mention of the
upstream project.

Otherwise, this is a very nice write up.  I'm mostly curious as our
setup uses an openldap directory server for identity and WinAD for
authentication.  realmd doesn't seem to cover (from a very cursory
glance) that arrangement.  So I have an eye out for how to best
leverage these things, if at all.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[John Florian]

On Mon, 2017-12-18 at 11:16 -0800, Adam Williamson wrote:
> Well, not quite. I installed Firefox rather a long time ago on this
> system. Again I can't prove it, but at that time I believe this
> question and preference referred *only* to 'data collection'. However,
> since then, a new sub-preference seems to have appeared, labelled
> 'Allow Firefox to install and run studies'. It appears, so far as I can
> tell, that they are claiming this promotional tie-in constituted a
> "study". That's a weak claim to start with, but more importantly, I am
> fairly sure this "Allow Firefox to install and run studies" preference
> was simply set to 'true' when it was *added* to Firefox. I was not
> asked. If I had been, I'm pretty sure I would've said no.

Count me in the same boat.  I hadn't noticed that option until now.  

However, before I toggled it off, I noticed the setting "Prevent
accessibility services from accessing your browser".  I briefly read
the "Learn more" for that feature and upon deciding that I have no need
for accessibility services at all, it was just better to toggle that
off.  Fx then wanted to restart for that change.  Much to my surprise,
when I got back to the security/privacy settings, the one for "Allow Fx
to install and run studies" had vanished ... and yes, the "Allow Fx to
send technical and interaction data to Moz" is still enabled.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Minor schedule procedure tweak (rain dates and such)

[John Florian]

Call me crazy, I don't mind, but what about scheduling the release
dates in reverse, using whatever naming scheme?  Then as the release is
finalized, we either stick to the last release date if there were lots
of "slips" or we select an earlier release date because things went
really well.  This might then be viewed as "Fedora released on time!"
or "Fedora released early!!!"

Full disclosure:
I'm left-handed so backwards things seem normal to me. :)

On Thu, 2017-11-02 at 15:55 -0400, Matthew Miller wrote:
> It turns out that the "Rain Date" concept is confusing to some people
> (particularly where that idiom is not familiar). I propose that for F28
> and onward, we keep the basic concept, but ditch that term. Instead, we
> use:
> 
> * Release Date Target 1
> * Release Date Target 2 (a week later).
> 
> As now, these will exist for both Beta and Final, and final will only
> be pushed back if Beta Target 2 is missed.
> 
> Then (and also new), if the Beta does slip past Target 2, we add a new
> "Target 3". If Beta slips to Target 3, Final slips to Target 2 (and we
> don't yet add a Target 3). If beta slips to Target 4, we cross off
> Final Target 2 and add Final Target 3.
> 
> I'm happy to bikeshed on calling "Target 1" something like "Early
> Target". Langdon suggested just dropping any adjectives (hence just "1"
> and "2", which works, but I want to balance between a feeling of "not
> really important because it's a fake target" (bad!) and journalists
> reporting "Fedora slipped once again, of course, because they're always
> late", no matter how much we explain the process to them.
> 
> 
> -- 
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[John Florian]

On Mon, 2017-10-16 at 15:03 +0100, James Hogarth wrote:
> On 16 October 2017 at 14:58, John Florian <j...@doubledog.org> wrote:
> > On Sun, 2017-10-15 at 09:23 -0700, Gerald B. Cox wrote:
> > >  people are going to notice is the improved performance and
> > > cleaner interface.
> > 
> > Yes!  Because of this thread's original message, I pulled 57 into
> > F26 eager to try it out (on $dayjob workstation).  Now I want it at
> > $home workstation.   Is there a COPR or some alternative for early
> > testers in F26 now that the update has been withdrawn?  I'd do more
> > looking on my own, but our corporate web proxy right now is eating
> > kittens and other helpless creatures and might as well be unplugged
> > for all the good it's doing me.
> > ___
> > 
> > devel mailing list -- devel@lists.fedoraproject.org
> > 
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> > 
> 
> I'm just writing up a Fedora Magazine article covering this at
> present ;)
> 
> I have a build running in a COPR now, and the article will include
> details of that.
> 
> Since we *are* on the development list where COPR is normal ... ;)
> 
> Up till the point FF57 rejoins updates-testing in F26 sometime in
> November I'm going to track commits to the F27/rawhide FF57 packages
> and build them for F25 and F26 for early testing.
> 
> https://copr.fedorainfracloud.org/coprs/jhogarth/firefox57/
> 
> The builds are completing at present ... once they have completed
> you'll be able to pick it up there.

Excellent!  Thank you for doing this.___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[John Florian]

On Sun, 2017-10-15 at 09:23 -0700, Gerald B. Cox wrote:
>  people are going to notice is the improved performance and cleaner
> interface.

Yes!  Because of this thread's original message, I pulled 57 into F26
eager to try it out (on $dayjob workstation).  Now I want it at $home
workstation.   Is there a COPR or some alternative for early testers in
F26 now that the update has been withdrawn?  I'd do more looking on my
own, but our corporate web proxy right now is eating kittens and other
helpless creatures and might as well be unplugged for all the good it's
doing me.___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCL and SELinux: help requested

[John Florian]

> On Fri, 2017-10-13 at 14:53 -0700, Kevin Fenzi wrote:
> > 
I don't know. Others have expressed frustration with selinux policy
> > maintainers of late as well. It's really hard to say what the trouble
> > is... are there to few of them? Overtasked with other work? Workflow too
> > difficult? Perhaps we can get FESCO or someone to work with them and try
> > and come up with a more open and working workflow. I'm not sure what the
> > answer is here.

I see it's not just me then that's noticed this.  It wasn't too long
ago that I could file a BZ and see updates later that day.  That was
unbelievably fast turnaround and made admin life so much easier.  I'd
rarely bother with a local policy to address such issues because they
were generally so temporary.  However, I've noticed with, at least
BZ#1448877 opened back in May, hasn't seem to have gotten the slightest
bit of attention.

I try to avoid local policies because I highly doubt that what I arrive
at is done as securely as it should be, but more importantly that
doesn't help anyone else out who's in or will be in the same situation.___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[John Florian]

On Thu, 2017-10-12 at 19:54 +0100, Richard W.M. Jones wrote:
> On Thu, Oct 12, 2017 at 09:05:33AM -0700, Kevin Fenzi wrote:
> > It's true that a number of older extensions will not work.
> 
> Well, looking at the most popular extensions:
> 
> https://addons.mozilla.org/en-GB/firefox/extensions/?sort=users
> 
> hardly any of them are parked as "compatible with firefox 57+".
> I'm counting 5/20 on the first page linked there, and 4/20
> on the first page of the highest rated extensions.
> 
> So I stand by my slightly modified claim that installing this update
> will disable most of your extensions.

I think you might be surprised how many *new* WebExtension alternatives
are available, but they are not yet popular when competing against the
*old* standbys.  IMHO, Mozilla could have done better with epoch
weighting, displaying the legacy tags far earlier -- those are really
quite recent.  I was also annoyed that I couldn't easily limit my
search for non-legacy extensions when using firefox < 57.

I learned about this incompatibility while dealing with an unrelated
issue in VimFx several months ago and was sad to learn that extension
would not be ported given the differences and the amount of time it
would require.  I began a panic search for replacements because of how
utterly dependent I am on some.  I think many popular extensions are
going to fall into this category if they're not backed by companies or
enthusiasts with lots of time.

So I'm happily testing from u-t now so I can convince myself everything
is going to be alright.  I'm not going to judge whether this via u-t
was correct or not; I've heard great arguments while perched atop of
the fence.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

self introduction

[John Florian]

Hi everyone,

I've lurked around here for years and occasionally have chimed in but
have never introduced myself.  What can I say, I'm left-handed and
generally backwards to most of society.  :-)Better late than never,
right?

My first exposure to any computer was a VIC-20 in 1981 and was the
ultimate gizmo for this (then) 13 year old.  My first exposure to any
*nix was AIX, heavily, in the early 90s, followed by Slackware,
lightly.  I really didn't do much Linux though until acquiring RHL 4.0,
but then I was hooked.  I remained an RHL user exclusively and followed
through to Fedora for until around FC3 then dabbled a bit with Ubuntu
but came back to Fedora circa FC7.

Since that time I've been doing rpm packaging internally for my
employer, though following the Fedora Packaging Guidelines to a large
extent as that generally helped ensure success.  A few years ago I
decided that my custom rpm build tools were limiting so I took the jump
into standing up our own Koji environment, along with Sigul, along with
more of my own tooling to fully automate the signing, mashing, etc.

All this helps me support my primary job developing our (er, my baby
actually) AOS (Appliance OS) and most of the applications that run atop
to fulfill various roles, which is now running on nearly 500
deployments, mostly embedded. The AOS is founded on what is effectively
a custom Fedora live image that leverages a fork of the fedora-
readonly.service along with a lot of clever leveraging of things that
Fedora already offered.  I dug deep, grokked, and tweaked, adding glue
and infrastructure as needed.

My interests are wide, but mostly are focused on system tools (I enjoy
being my own best customer :-) and automation. I'm heavily biased
towards Python, but also necessarily extremely well versed in shell
scripting. I also do lots of Puppet (a love/hate relationship), some
Ruby and more. I don't have any particular package I want to bring to
Fedora at this time so I'll stick with package reviews for the time
being.  Maybe someday I'll try to pry loose one of my many personal
and/or work packages.  I've already slowly started trickling out my
Puppet modules (at https://github.com/jflorian).  When I'm away from a
computer, I'm often busy with home alterations and renovation, wood
working, metal working, or feeding my insatiable appetite for books,
music, nature, and learning.

Finally, I would like to thank (again) Zbigniew for both offering an
welcoming hand at just the right moment and for sponsoring me as a
Fedora Packager.___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedorahosted.org sunset is next week!

[John Florian]

On Tue, 2017-02-21 at 10:22 -0700, Kevin Fenzi wrote:
> Greetings. 
> 
> As noted in: 
> 
> https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/message/RLL3LFUPLYMAUKGZ5B3O64XKJXBT24KZ/
> https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/message/BWSMCGZPPNG3JOCFQ6Z74MIBU7FG3KGB/
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/BWSMCGZPPNG3JOCFQ6Z74MIBU7FG3KGB/
> 
> fedorahosted is getting retired soon (next week!). 
> 

Hopefully this means Google will catch on.  I've been rather frustrated
at how often the old fedorahosted is shown in the search results up top
and how burried the Pagure instance can be.  It's been getting better,
but perhaps that's only Google learning what *I* want.  I've had to get
in the habbit of searching for "koji pagure" or "lorax pagure".  The
latter will probably always require something extra because Dr. Seuss
is the order of the day it seems.  :-/___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: nfs-utils-2.1.1 Changes Everything!

[John Florian]

On Mon, 2017-01-16 at 15:11 -0500, Steve Dickson wrote:

Hello,

The latest nfs-utils release drastically changes how the NFS
servers are configured, for the good IMHO...

All daemon  configuration now goes through /etc/nfs.conf.
See nfs.conf(5) for details.

The command line interfaces in the systemd services files
have been removed. Which means all your current configures
will break, because the variables in /etc/sysconfig/nfs are
no longer used.

Again, I think is a move in the right direction and I know
you might find this surprising 8-) but I really don't want to
break all the current server configuration. So I'm trying t
o figure out how to do this with least amount of impact.

Here is what I see as the options

1) Upgrade rawhide w/out a backward compatible patch
(since it is so early in the release cycle)
Upgrade f25 with an backwards compatible patch

2) Upgrade rawhide and f25 with the backward compatible
patch... but we have to ween ourselves of the command
line interface at some point...

3) Do nothing and push everything into f27, which is the least
favorite option.

I'm leaning toward option 1... but I'm asking... so I'm listening. :-)

Also, how do I documented something like this?

tia,

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



I'd only ask that the transition only occur in a clean break between OS 
releases. For those of us managing Puppet, Ansible, etc. it's hard to be 
adaptive to these things unless there's a good condition we can use. It sounds 
like all your proposals would achieve that, but I thought I ought mention it 
anyway.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: future of official optical media support in Fedora

[John Florian]

On Fri, 2016-12-16 at 15:49 -0600, Pete Travis wrote:
All the DRAC/iLO/BMC systems I play with these days mount a remote ISO and 
present it as optical media. The feature is basically only used for emergencies 
where regular networking won't do,

My co-workers use iDRAC installs for non-emergency cases. We need to ships 
servers around the world and sometimes the import laws are such a PITA that's 
easier to have the facility make the hardware purchase locally and then said 
co-workers install Fedora remotely via the DRAC.

I've not done it myself so I cannot speak at all as to how various media types 
work or fail, but just thought I'd mention that this type of scenario is very 
real, albeit admittedly much less common.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Un-retiring QCad

[John Florian]

On Tue, 2016-12-13 at 19:45 +0100, Kevin Kofler wrote:

Przemek Klosowski wrote:


The reason why I'm asking is that I believe that in general FOSS
projects should fork as little as possible, and merge as much as
possible, to avoid duplication of effort. There are circumstances where
the fork is the only solution, of course, and I am asking what are the
circumstances in this case.



In this case, it looks like they forked because of the totally closed
development structure of the upstream project and its unwillingness to port
from Qt 3 to Qt 4. By now, we are in Qt 5 era, and the projects have
diverged so much that a merger is highly unlikely.


I haven't followed the fork -- I didn't even realize it existed until this 
thread -- I stayed with upstream, even buying a license for a few years. While 
it'd be nice to see it move along to a newer Qt, I've been very impressed with 
the feature additions since it became closed and open again. I'm equally 
unimpressed with his build processes; one glaring example is 
http://www.qcad.org/bugtracker/index.php?do=details_id=1369. I started 
packaging it for myself just to work around such issues.

So I'm curious, has the fork maintained any sort of feature parity? Did it 
adopt Qt 4 or 5? If not, I'd much prefer to see the upstream product make it 
back to Fedora. If the fork does use a newer Qt but hasn't progressed much 
feature-wise then I don't know what to think of the situation other than it 
sucks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

[John Florian]

On Thu, 2016-12-01 at 13:32 -0800, Howard Howell wrote:
On Thu, 2016-12-01 at 21:25 +, John Florian wrote:
On Thu, 2016-12-01 at 12:55 -0800, Adam Williamson wrote:

On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:



Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
So removing it is tearing the rug out from under all those others?



Well, I don't think so, as I'd expect that to rip out much *more*
stuff. I think it must be something a bit more odd than /usr/bin . The
'filesystem' package provides /usr/bin too, and that ought to be
installed.


That's a good point.  What does `rpm -V filesystem` show?

___



Nothing!# rpm -V filesystem
#

I think you're in good shape then.  It sounds like the `rpm -e` did what was 
needed and you're now back to a more normal Fedora.  I suspect your upgrade 
will go smoothly now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

[John Florian]

On Thu, 2016-12-01 at 12:55 -0800, Adam Williamson wrote:

On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:



Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
So removing it is tearing the rug out from under all those others?



Well, I don't think so, as I'd expect that to rip out much *more*
stuff. I think it must be something a bit more odd than /usr/bin . The
'filesystem' package provides /usr/bin too, and that ought to be
installed.


That's a good point.  What does `rpm -V filesystem` show?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Announcement: Python 3 port of livecd-creator (was: Re: Announcement: DNF port of livecd-creator)

[John Florian]

On Mon, 2016-11-14 at 12:35 -0500, Neal Gompa wrote:

On Mon, Nov 14, 2016 at 12:17 PM, John Florian 
<john.flor...@dart.biz<mailto:john.flor...@dart.biz>> wrote:


On Sun, 2016-11-13 at 05:03 +0100, Kevin Kofler wrote:

Hi,

FYI, Neal Gompa has now put up a Copr with the DNF + Python 3 version of the
livecd-tools:
https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/



This is interesting news for me.  I'm a long time user (in an employed
capacity) of livecd-tools and it sort of felt like the project was circling
the drain.  I've recently started playing with livemedia-creator and have
found some aspects that look wonderfully powerful (e.g., the lorax
templates) but have also found it frustrating to use when it doesn't like my
kickstart.  I'm past that frustration (for now), but have hit another bump.
To make the spins from lm-c into what I need, I must modify the lorax
templates and since our spins are done in our Koji there doesn't yet appear
to be anyway to achieve that.




In order to use alternative templates, the livemedia-creator command
must have an additional parameter passed. Koji currently doesn't
support this facility, which makes it difficult to use when you need
to support custom layouts. If you'd like this capability, file a bug
against koji in bugzilla for it.


Done.  https://bugzilla.redhat.com/show_bug.cgi?id=1394933

I'm willing to try tackling this.  I code Python lots and have read plenty of 
Koji (to understand how to use it before the excellent 
https://docs.pagure.org/koji came along ... or maybe that's been around for 
awhile and I just never stumbled onto it working only with "better than 
nothing" https://fedoraproject.org/wiki/Koji).  If that's acceptable, should 
this be planned on buildsys or koji-devel first or should I just go for it and 
show my work as a patch on the RFE I submitted or ... ?





So I'm at a crossroad of enhancing Koji to support custom lorax templates or
to maybe hold out for this breath of life in livecd-tools.  Are you planning
to get this work into the livecd-tools in the standard Fedora repos?  What
about Koji support?  Would this work as is or will that require further
work?




Kevin has already submitted a request to merge our work into the
canonical livecd-tools repository[1]. Once merged, we hope that
upstream will push a new release to supported releases with the new
code.

Cool beans!


 The work we did shouldn't affect Koji support any, though if you
run Koji on something other than Fedora, you'll need to have the
latest DNF 1.1 version available on the system running Koji. With the
release of RHEL 7.3 and EPEL7 subsequently bumping up to it, the
version of DNF for EL7 can be bumped to the latest 1.1 release. Please
request that in bugzilla, if you want it.

I'm currently not providing EL7 packages because of the lack of DNF
1.1. With no CentOS 7.3 available yet, I cannot produce packages that
would be installable by the vast majority of people.


Will do.  I'll probably wait until CentOS 7.3 is out.  Unfortunately I don't 
have any proper RHEL to play with.  Then that always puts my brain in a spin as 
to where I *should* file such requests, CentOS BZ, RH BZ, github, etc.  I feel 
wrong (and have been told so for other rpms) in filing in RH BZ when I expect 
to use it in CentOS, but if RH *is* upstream like with lorax, then anywhere 
else seems wrong.



[1]: https://github.com/rhinstaller/livecd-tools/pull/37



I'm just trying to gauge where to focus my efforts project-wise.  Hopefully
I can contribute something here.



I would encourage you to try out our new livecd-tools and see how it
performs for your needs. Contributions are welcome as well. If
upstream doesn't pull it in, the code will be maintained on Kevin's
GitHub repository[2].

[2]: https://github.com/kkofler/livecd-tools


I will do that. It's always an immense relief for me to see things moving to 
Python 3 -- I jumped ship long ago, and of course, now I want everything else 
to do the same.  Even if I do wind up using livemedia-creator eventually for 
composing the ISO, I'll still be using copy-iso-to-disk from livecd-tools for 
some time to come for the persistent storage support.  I'll be more than happy 
to help test.  Hopefully I can also contribute something as well, which is much 
more likely with Py3 code because it doesn't burn my eyes like Py2 does.  [:-)] 
​
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Announcement: Python 3 port of livecd-creator (was: Re: Announcement: DNF port of livecd-creator)

[John Florian]

On Sun, 2016-11-13 at 05:03 +0100, Kevin Kofler wrote:

Hi,

FYI, Neal Gompa has now put up a Copr with the DNF + Python 3 version of the
livecd-tools:
https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/




This is interesting news for me.  I'm a long time user (in an employed 
capacity) of livecd-tools and it sort of felt like the project was circling the 
drain.  I've recently started playing with livemedia-creator and have found 
some aspects that look wonderfully powerful (e.g., the lorax templates) but 
have also found it frustrating to use when it doesn't like my kickstart.  I'm 
past that frustration (for now), but have hit another bump.  To make the spins 
from lm-c into what I need, I must modify the lorax templates and since our 
spins are done in our Koji there doesn't yet appear to be anyway to achieve 
that.

So I'm at a crossroad of enhancing Koji to support custom lorax templates or to 
maybe hold out for this breath of life in livecd-tools.  Are you planning to 
get this work into the livecd-tools in the standard Fedora repos?  What about 
Koji support?  Would this work as is or will that require further work?

I'm just trying to gauge where to focus my efforts project-wise.  Hopefully I 
can contribute something here.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns

[John Florian]

On Mon, 2016-10-10 at 11:42 -0400, Matthew Miller wrote:

 I think the hardware on which Fedora will run well which cannot boot from USB 
media is
vanishingly small.


Like the piece of crap Samsung notebook I bought new in 2012.  [:-/] ​

Using optical media feels so dirty, though I guess it does give me an excuse to 
use up that tower of blank discs.  Thank goodness for in-place Fedora upgrades.

--

John Florian <john.flor...@dart.biz<mailto:john.flor...@dart.biz>>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[John Florian]

On Fri, 2016-10-07 at 12:38 -0700, Adam Williamson wrote:

On Mon, 2016-10-03 at 20:03 +, John Florian wrote:


On Mon, 2016-10-03 at 12:07 -0700, Adam Williamson wrote:
If we do not 'support' livecd-iso-to-disk any more, we no longer
support:

1) persistent storage (via overlays)
2) non-destructive write


I've known for quite some time that livecd-tools was/is to be
replaced with livemedia-creator, but only now did I realize that lm-c
won't have persistent storage -- I simply have never had the time to
explore it.  I'm extremely dependent on the persistent storage as my
whole day job revolves around making hundreds of little mostly-
stateless appliances for data collection purposes and has so since
F13 or so.  These have been built with livecd-iso-to-disk and lots of
glue via specialized kickstarts and other custom packages.  These
appliances leverage a stateless OS very robustness, but do expect
some persistent storage for their management.  So the above certainly
caught my attention.



There's a slight misconception in the above.

livemedia-creator *creates the image files themselves*. We're not
talking about that in this thread. We're talking about the tools for
taking an image that's been created - whether by livecd-creator or
livemedia-creator or anything else - and writing them to a USB stick.


I'm fine with that and I think it matches my understanding/expectations.  Do 
one thing and do it we



The 'persistence' feature requires support both in the image itself and
in the tool used to write it. I believe livemedia-creator-produced
images are set up to support persistence, just like livecd-creator-
produced images were.


I suspect this "support within the image" overlaps with some of the glue to 
which I referred.  Once upon a time these live images auto-mounted their 
backing storage (where the immutable squashfs image is kept).  Then that 
stopped working and I had to write an init service to do the same.  Whether 
that service is still needed or not, I haven't investigated -- it's been 
working happily.



The issue here is that we are discussing what tools for *writing the
image to a USB stick* should be 'supported' / 'recommended' / whatever,
and we'd kinda like to drop livecd-iso-to-disk from that group, but it
is currently the only one of the 'write image to stick' tools which
supports persistence.

No-one's proposing dropping livecd-iso-to-disk entirely at present, so
you will still be able to attempt to write sticks with persistent
storage, but we are discussing effectively a downgrade in how much
testing it gets and how much we care if it's broken.


I'm fine with all that.  I certainly don't expect Fedora to cater to my 
specific needs, but I like to chime in now and then if it might help preserve 
some feature that everyone might otherwise feel is unused.



It is worth noting that we've never formally tested the persistence
features in any case, so we would never have blocked a release for
'persistence doesn't work right' anyhow. But at present we do, by
policy, block the release if writing sticks with livecd-iso-to-disk
doesn't work.


No worries there.  I/we've been testing it exhaustively.  When I push an update 
to hundreds a machines (most of which are headless/keyboard-less and ill-suited 
for such attachments and work) that all deploy it autonomously, it has to "just 
work".  Though I would never suggest our mutation reflects what the real Fedora 
is doing.  [:-)] ​





Are there plans to get persistent storage capabilities into lm-c?

Also, after much work I managed to get my live ISO spins generated
out of a private Koji setup.  I see there a warning "spin-livecd is
deprecated and will be replaced with spin-livemedia" -- I assume this
related, true?  If so, do any improvements to lm-c (say to add
persistence) automagically benefit the "spin-livemedia" method in
Koji?



Well, yeah. 'spin-livecd' is the Koji method for creating images with
livecd-creator; it's now deprecated and never used in the official
Fedora Koji instance, Fedora live images are all now created with the
'spin-livemedia' method. 'spin-livemedia' is the Koji method for
creating images with livemedia-creator.



So since what 'spin-livemedia' *does* is create a live image using
livemedia-creator, of course any changes to livemedia-creator will be
reflected when you create an image with the Koji 'spin-livemedia'
method.


Thanks for all the feedback Adam.  I'll start playing around with 
livemedia-creator to learn how my world needs to transform.  It will be 
interesting to see how this all dovetails with the stateless support[0] that 
the systemd folks have (had?) been working on.

[0] http://0pointer.net/blog/projects/stateless.html

--

John Florian <john.flor...@dart.biz<mailto:john.flor...@dart.biz>>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[John Florian]

On Mon, 2016-10-03 at 12:07 -0700, Adam Williamson wrote:
If we do not 'support' livecd-iso-to-disk any more, we no longer
support:

1) persistent storage (via overlays)
2) non-destructive write


I've known for quite some time that livecd-tools was/is to be replaced with 
livemedia-creator, but only now did I realize that lm-c won't have persistent 
storage -- I simply have never had the time to explore it.  I'm extremely 
dependent on the persistent storage as my whole day job revolves around making 
hundreds of little mostly-stateless appliances for data collection purposes and 
has so since F13 or so.  These have been built with livecd-iso-to-disk and lots 
of glue via specialized kickstarts and other custom packages.  These appliances 
leverage a stateless OS very robustness, but do expect some persistent storage 
for their management.  So the above certainly caught my attention.

Are there plans to get persistent storage capabilities into lm-c?

Also, after much work I managed to get my live ISO spins generated out of a 
private Koji setup.  I see there a warning "spin-livecd is deprecated and will 
be replaced with spin-livemedia" -- I assume this related, true?  If so, do any 
improvements to lm-c (say to add persistence) automagically benefit the 
"spin-livemedia" method in Koji?


--

John Florian <john.flor...@dart.biz<mailto:john.flor...@dart.biz>>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to package a Git repository

[John Florian]

On Fri, 2016-09-09 at 16:54 +0200, Igor Gnatenko wrote:
Problem with tito as it doesn't really do proper archive for
build/release and doesn't work properly in many cases:
1. Version is specified in spec -> all builds will be unordered.
Example: Version: 2.0.0 -> 2.0.0-1.git.tree-ish

I don't have any problem with this at all.  For my test builds I don't use 
tito.release.KojiGitReleaser
 but rather tito.release.KojiReleaser which produces builds named like:

builder-6.14-1.git.6.05be4b1.fc24
builder-6.14-1.git.7.40346c1.fc24
builder-6.14-1.git.8.c448a30.fc24

... where the '.6', '.7', '.'8' following represents the number of commits 
since the last "tito tag" operation.  I only get burned when redo one of those 
"steps" with "git commit --fixup" followed later by "git rebase -i 
--autosquash".  However, by that time I'm finalizing a branch and can live with 
a reinstall vs upgrade.


2. Replaces archive. Source: https://.../%{name}-%{version}.tar.gz is
404 as tito creates releases in %{name}-%{version}-X where X is
release. If we are talking about Github, then even you change URL to
proper it still doesn't work because %(auto)setup fails, as github
generates archive in %{name}-%{name}-%{version}-X format.

I'm not 100% sure I follow you here, but I suspect I get away with this because 
all my spec's have:

​​Source0:%{name}-%{version}.tar.gz

Granted, this would never fly in Fedora proper, but for private work it suits 
me fine.  I otherwise attempt to adhere to FPG as much as possible as it 
generally makes life simpler.

X. Requires some files in upstream repo

I'm not sure I follow here either, but as the author and packager for my 
projects, I actually prefer that our Git repo has everything needed, spec, 
Makefile, etc. right there.  The only part that makes me cringe is the fact 
that Makefile is duped all over the place.  I hate dupes and strive for DRY 
because eventually they all need to change.

I would not recommend using tito. I would recommend to have spec in
upstream ONLY for reference, but have proper Fedora ones in our
dist-git.

In my case (but perhaps not Mr. Weimer's) is that I don't have to be proper per 
Fedora.  FWIW, I found tito to be a godsend for bringing ease to my situation.

That all said, I'm very curious how your rpm-gitoverlay helps exactly.  I've 
found a solution that works for me, but I hammered out a solution without as 
broad an understanding of how Fedora is built as I have now -- and I'm certain 
my current understanding is probably woefully lacking.  Is rgo something that 
could be used with our private Koji setup?  My quick glance at the code leads 
me it's suited for copr or rpmbuild only.


--

John Florian <john.flor...@dart.biz<mailto:john.flor...@dart.biz>>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to package a Git repository

[John Florian]

On Fri, 2016-09-09 at 11:25 +0200, Florian Weimer wrote:

I would like to build (S)RPMs directly from a Git repository (which
contains the .spec file in the top-level directory).  This is for a
CI-style project, with a quick release cycle.

I have a Lua script fragment which generates a proper SRPM with the
mock-scm target in COPR, and which is also compatible with “fedpkg
srpm”.  But rpmbuild strips leading path components from Source: and
Patch: references, so this only works if all files are in a single
directory.

Are there any alternatives that work in COPR, EPEL and Fedora proper?

I think it's strange that I have to put a tarball somewhere just for
RPM's sake if there is no separate upstream, and there are no upstream
releases as a result.  It's just an annoyance and yet another step that
can go wrong in various ways.


This is my situation with everything I package (privately for my employer).  I 
went in circles for a while simply believing I had to be doing something wrong 
until I considered the fact that most people doing packaging are not the 
authors.  This all settled in completely when I began recalling the days of 
yore when one would download a tgz, extract, config, make, etc..  Still I think 
it's a shame that this isn't handled better.  With very large projects it's 
quite a waste of time to archive just to meet the expected input format only to 
have the process reversed immediately.

That said, I do much as Igor has already mentioned.  My build process starts 
with tito but lands in our Koji.  I use the following Makefile without any 
changes for each of my projects to facilitate tito's 
tito.release.KojiGitReleaser:

$ cat Makefile
# Extract NVR from the spec while stripping any macros, specifically the
# disttag macro.
name := $(shell awk '/^Name:/{print $$2}' *.spec)
version := $(shell \
   awk '/^Version:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
   )
release := $(shell \
   awk '/^Release:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
   )
# The treeish we'll archive is effectively the Git tag that tito created.
treeish := ${name}-${version}-${release}

# Koji's buildSRPMFromSCM method expects a target named "sources" which
# ultimately must ensure that a tarball of the package's sources and its spec
# file are present.  Our practice is to always keep a spec file in the Git
# repository, but we must build the tarball on the fly to resemble an upstream
# published work.
sources:
   git archive \
   --output=${name}-${version}.tar.gz \
   --prefix=${name}-${version}/ \
       ${treeish}


Hope this helps!
--
John Florian <john.flor...@dart.biz<mailto:john.flor...@dart.biz>>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: KillUserProcesses=yes by default

[John Florian]

On Fri, 2016-07-29 at 11:31 -0600, Chris Murphy wrote:
> Can anyone explain why the feature works for Logout, but doesn't work
> for Restart or Shutdown when initiated in the logged in shell
> session?

Aha!  I manually enabled this for F23 hoping to eliminate the 90s wait
I seem to get on every exit.  It seemed to rarely have any benefit
though and now I see why: I typically only use the reboot feature!
-- 
John Florian <john.flor...@dart.biz>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: /var/run/reboot-required

[John Florian]

On Wed, 2016-07-27 at 08:16 -0400, Josh Boyer wrote:
> On Wed, Jul 27, 2016 at 5:43 AM, Ruben Kerkhof <ru...@rubenkerkhof.co
> m> wrote:
> > 
> > Hi all,
> > 
> > Debian and Ubuntu have a package called unattended-upgrades.
> > We have yum-cron which does something similar.
> > 
> > One difference though is that unattended-upgrade drops a script in
> > /etc/kernel/postinst.d/unattended-upgrades, which does this:
> > 
> > #!/bin/sh
> > if [ -d /var/run ]; then
> >    touch /var/run/reboot-required
> > fi
> > 
> > Using Ansible, I can quickly see which servers need a reboot due to
> > a
> > kernel upgrade.
> > 
> > I think this would be nice to have in Fedora as well, the only
> > question is which package
> > should provide it.
> > 
> > We have /etc/kernel/postinst.d too, but this directory is currently
> > unowned.
> > So if I'd wanted to add this to some package, which one should it
> > be
> > and what should it depend on?
> > 
> > Alternatively, I could create a new package, let's call it 'reboot-
> > required'.
> > 
> > Thoughts?
> Why would you want this to be something packaged?  We have 'reboot
> recommended' in our bodhi update metadata, and that seems like a much
> better place for it.  Otherwise, you run into cases where multiple
> packages want to write/own the file, etc.
> 
> Also, I think "recommended" is really the appropriate terminology
> here.  There is very little that _requires_ a reboot to be done after
> it is installed.

How can this metadata be leveraged with automation?  I have the dnf
tracer plugin which I believe is using this metadata to tell me when I
need to reboot, but what if I have this in a cron job?
-- 
John Florian <john.flor...@dart.biz>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

RE: Why GUI software update tool is broken for me

[John Florian]

> From: Jonathan Wakely [mailto:jwak...@fedoraproject.org]
> Sent: Thursday, June 16, 2016 10:14
> To: Development discussions related to Fedora
> Subject: Re: Why GUI software update tool is broken for me
> 
> On 16/06/16 13:39 +, John Florian wrote:
> >Oh cool and here I've been waiting to have this available outside of
> GNOME (as a Plasma user).  However, I'm confused by my first experiment
> with it:
> >
> >
> >$ sudo pkcon update --only-download
> >Getting updates   [=]
> >Finished  [=]
> >No packages require updating to newer versions.
> >
> >$ sudo dnf update
> >No read/execute access in current directory, moving to /
> >Last metadata expiration check: 0:03:28 ago on Thu Jun 16 09:30:07 2016.
> >Dependencies resolved.
> >=
> ===
> > Package Arch  Version
> RepositorySize
> >=
> ===
> >Installing:
> > double-conversion   x86_642.0.1-6.fc23
> local-fedora  44 k
> >Upgrading:
> > NetworkManager-l2tp x86_641.0.2-2.fc23
> local-updates 84 k
> > autocorr-en noarch1:5.0.6.2-
> 7.fc23  local-updates204 k
> >
> >util-linux  x86_642.28-2.fc23
> local-updates2.2 M
> >
> >Transaction Summary
> >=
> ===
> >Install   1 Package
> >Upgrade  59 Packages
> >
> >Total download size: 187 M
> >Is this ok [y/N]: n
> >Operation aborted.
> >
> >
> >Why would that be?
> 
> PackageKit and DNF use separate caches, which are not updated at the
> same time. Try "pkcon refresh" first to update its cache.


Ok, I tried that but it made no difference.  Does pkcon use /etc/yum.repos.d/?


--
John Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

RE: Why GUI software update tool is broken for me

[John Florian]

> From: Stephen Gallagher [mailto:sgall...@redhat.com]
> Sent: Wednesday, June 15, 2016 12:51
> To: devel@lists.fedoraproject.org
> Subject: Re: Why GUI software update tool is broken for me
> 
> 
> People *can* use the command-line to get the reboot behavior:
> ```
> pkcon update --only-download
> pkcon offline-trigger
> reboot

Oh cool and here I've been waiting to have this available outside of GNOME (as 
a Plasma user).  However, I'm confused by my first experiment with it:


$ sudo pkcon update --only-download
Getting updates   [=] 
Finished  [=] 
No packages require updating to newer versions.

$ sudo dnf update
No read/execute access in current directory, moving to /
Last metadata expiration check: 0:03:28 ago on Thu Jun 16 09:30:07 2016.
Dependencies resolved.

 Package Arch  Version  
 RepositorySize

Installing:
 double-conversion   x86_642.0.1-6.fc23 
 local-fedora  44 k
Upgrading:
 NetworkManager-l2tp x86_641.0.2-2.fc23 
 local-updates 84 k
 autocorr-en noarch1:5.0.6.2-7.fc23 
 local-updates204 k

util-linux  x86_642.28-2.fc23   
local-updates2.2 M

Transaction Summary

Install   1 Package
Upgrade  59 Packages

Total download size: 187 M
Is this ok [y/N]: n
Operation aborted.


Why would that be?
--
John Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org