[Bug 1584156] perlbrew-0.83 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1584156
Bug 1584156 depends on bug 1584222, which changed state.

Bug 1584222 Summary: Review Request: perl-Test-TempDir-Tiny - Temporary 
directories that stick around when tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1584222

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org/message/XZPWJTTGEXFJNUIQMU27UEOS42JXNSUH/

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

[Kyle Marek]

With respect, I am opposed to the proposal.

In essence, I think this boils down to: function > form.

I've been in too many situations where hidden GRUB menus resulted in
having to "guess" when the firmware has finally started the bootloader
and what would be a quick 5 second cmdline change turns into several
minutes of rebooting due to ESC entering the firmware configuration...
I've had similar experiences with F8 in Windows environments.

While this may be a "simple 1 time configfile change," having to enter
the menu is often an unexpected scenario so remembering to do this
*before* you run into some boot-related issue is in-itself an issue,
especially when the user has many machines/installations.

As pointed out, the plans to have a 0 second timeout in F30, requiring
some userspace preparation to enable the menu, is going to result in
issues where additional boot media is necessary if the system boots fine
but the user cannot actually log into the system.

Furthermore, the GRUB menu's "only function" is not just to allow
booting older kernels. In fact, I've personally never had to boot an
older kernel; I've only ever used the menu for cmdline edits to address
all kinds of random issues (including but not limited to graphics
issues), or to address things that weren't even "issues" (enabling
intel_iommu, for example). I often try several cmdline edits before
progress is made on a specific issue.

I think going through this effort to shave a few seconds off of the boot
time is just going to make everything harder *especially* when the shit
hits the fan... I don't think it's worth perpetuating the
Windows-ification of Fedora, either.

Regards,

    Kyle

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

Old deltarpms are being thrown away on each compose (was Re: dnf and deltarpm)

[Jonathan Dieter]

On Thu, 2018-05-31 at 22:34 +0100, Tomasz Kłoczko wrote:
> Just checked on few mirrors usual location of f28 updates
> (/pub/linux/dist/fedora/linux/updates/28/Everything/x86_64/drpms) and
> in this directory there are at the moment only 56 files from May 31
> and nothing older. So not two drpm per RPM package but only generated
> files out of last batch of updates.

(CC'ing the Fedora infrastructure list)

This is a bug.  It looks like we're throwing away any drpms not
generated in this compose, when we should be keeping them.

I've just created:
https://pagure.io/fedora-infrastructure/issue/7008

Jonathan
___
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/DSHBJB2D3ZSXMSFIZY7MZELKSI6PUAMA/

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

[Akarshan Biswas]

100% agreed. how ever enable an option to automatic enable grub bootloader menu 
when something went wrong with the boot process, or system crash. This will 
help alot to users like me. :)
___
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/FYL2FHV5QZEEFTLWOK4UX67HRPLBQ6UY/

[389-devel] 389 DS nightly 2018-06-01 - 60% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/06/01/report-389-ds-base-1.4.0.9-20180531gitd09a57d.fc28.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org/message/4CQOXNJ7WK2KJGH2S2UEAPE2TBKIZTOZ/

Re: Firefox with native Wayland backend at updates

[mcatanzaro]

On Thu, May 31, 2018 at 5:39 PM, Kevin Kofler  
wrote:
We try hard to avoid messy menus with duplicate entries, and you get 
away
with adding an extra desktop entry to an application installed by 
default on

almost all Spins, for an experimental option?


Ugh yes, thanks for pointing this out, Kevin. I just assumed it had 
been done as a new desktop action in the existing desktop file (fairly 
hidden and harmless), but it's actually a new desktop file.


Please remember that, if your package is installed by default in 
Workstation, the working group should approve any new visible desktop 
files, as the default desktop launchers are carefully-curated.


Martin, can you please fix this? I suggest adding a new desktop action 
to the existing desktop file instead, or else split the new Wayland 
desktop file into a subpackage that would need to be installed manually 
for the launcher to appear.


Thanks,

Michael
___
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/DVXMTYUDV7QEQHG2RPORUUY66VPAOIZ6/

I'm travelling and offline until the 18th

[Kalev Lember]

Just a quick heads up that I won't be online if you are looking for me.
hughsie is running point on GNOME builds while I'm gone.

Kalev
___
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/BRN47AJCJCJ3326U4XNSPVZSULIBBUZX/

Re: F29 System Wide Change: Hide the grub menu

[Gerald B. Cox]

On Thu, May 31, 2018, 20:19 Ben Rosser  wrote:

> On Thu, May 31, 2018 at 6:31 PM, Adam Williamson
>  wrote:
> > On Thu, 2018-05-31 at 15:58 -0400, Ken Coar wrote:
> >> At 2018-05-31T02:36, Jason L Tibbitts III irritated the
> >> Akashic Field to say:
> >> >
> >> > If a user is technical, and our documentation is reasonably good,
> >> > then they should be able to achieve the level of verbosity they want.
> >>
> >> When you need to get into single-user mode, the documentation
> >> is probably not to hand. :-)
> >>
> >> How about making this a yes/no installation option?
> >
> > http://islinuxaboutchoice.com/
>
> But my somewhat
> cynical observation is that people usually pull out the "Linux isn't
> about choice" card when they are trying to justify some choice they
> have made and want others to adopt.
>

Amen.  It's one of the guiding principles of gnome-ification.  But it isn't
the topic at hand.  As you mention and as I stated much earlier in the
thread if you want to change the default behavior... fine - - - but update
the documentation so people know how to change it back or invoke it as
needed.

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

Re: F29 System Wide Change: Hide the grub menu

[Ben Rosser]

On Thu, May 31, 2018 at 7:29 PM, Adam Williamson
 wrote:
> On Thu, 2018-05-31 at 19:19 -0400, Ben Rosser wrote:
>> So, back to the topic of this thread: while I don't think this choice
>> belongs in the installer, I do think there should be detailed
>> instructions somewhere for end users on how to enable or disable the
>> grub boot menu, so they can _choose_ the behavior that they want. A
>> quick Google search for "fedora hide grub menu" turned up a blog post
>> or two, an ask.fp.o post, a couple forum threads, and a Stack Exchange
>> post as the first few results, which makes me believe it's not
>> currently well explained anywhere in our documentation?
>
> There's nothing Fedora-specific about it. It's just a grub config
> option.

Well, yes, that's true. But, from the justification presented earlier
in this thread, it seems like this change proposal is geared around
less technical users who may not know this?

My assumption right now is that there are people unhappy with seeing
the boot menu and want to not see the boot menu, hence this change
proposal. (If that's not true then I'm not sure why we should change
the behavior to begin with). If we don't change the default, we should
at least make sure they know how to get the behavior we want. And it
presumably goes without saying that if we do change the default, we
should document what was changed and how to get back the old behavior.

I think that philosophy applies even though this is nothing specific to Fedora.

Ben Rosser
___
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/CTTRIOGRT3SEY3NEGC3SOVHTUWJUPHOK/

Re: F29 System Wide Change: Hide the grub menu

[Adam Williamson]

On Thu, 2018-05-31 at 19:19 -0400, Ben Rosser wrote:
> So, back to the topic of this thread: while I don't think this choice
> belongs in the installer, I do think there should be detailed
> instructions somewhere for end users on how to enable or disable the
> grub boot menu, so they can _choose_ the behavior that they want. A
> quick Google search for "fedora hide grub menu" turned up a blog post
> or two, an ask.fp.o post, a couple forum threads, and a Stack Exchange
> post as the first few results, which makes me believe it's not
> currently well explained anywhere in our documentation?

There's nothing Fedora-specific about it. It's just a grub config
option.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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/KISYBFZZRFCJU2REFRA3LMWSXFI7O2X5/

Re: F29 System Wide Change: Hide the grub menu

[Adam Williamson]

On Thu, 2018-05-31 at 20:18 -0300, Gerald B. Cox wrote:
> On Thu, May 31, 2018, 19:32 Adam Williamson 
> wrote:
> 
> > 
> > > How about making this a yes/no installation option?
> > 
> > http://islinuxaboutchoice.com/
> 
> 
> Well... That's a bit of a non-sequitur...

Well, to unpack a bit: "let's just slap a choice in the installer!" is
almost never the right answer.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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/7FQMGVHHQCBGFETTH7WZ2GYE6H3ZF3RF/

Re: F29 System Wide Change: Hide the grub menu

[Gerald B. Cox]

On Thu, May 31, 2018, 19:32 Adam Williamson 
wrote:

>
> > How about making this a yes/no installation option?
>
> http://islinuxaboutchoice.com/


Well... That's a bit of a non-sequitur...

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

Re: F29 System Wide Change: Hide the grub menu

[Ben Rosser]

On Thu, May 31, 2018 at 6:31 PM, Adam Williamson
 wrote:
> On Thu, 2018-05-31 at 15:58 -0400, Ken Coar wrote:
>> At 2018-05-31T02:36, Jason L Tibbitts III irritated the
>> Akashic Field to say:
>> >
>> > If a user is technical, and our documentation is reasonably good,
>> > then they should be able to achieve the level of verbosity they want.
>>
>> When you need to get into single-user mode, the documentation
>> is probably not to hand. :-)
>>
>> How about making this a yes/no installation option?
>
> http://islinuxaboutchoice.com/

I know that this page was created by Fedora developers, so this is
probably going to be an unpopular opinion here, but...

I've always found this argument incredibly suspect (and, frankly, the
page overly condescending). At its core, for users (especially desktop
users), using Linux at all very frequently _is_ a choice. The choice
to use open source software at all is, well, a choice. They are
choosing to install an operating system that is open source on
hardware that probably didn't come with it.

Now I do agree that this does not mean the development of a Linux
distribution necessarily has to be "about choice". But my somewhat
cynical observation is that people usually pull out the "Linux isn't
about choice" card when they are trying to justify some choice they
have made and want others to adopt.

So, back to the topic of this thread: while I don't think this choice
belongs in the installer, I do think there should be detailed
instructions somewhere for end users on how to enable or disable the
grub boot menu, so they can _choose_ the behavior that they want. A
quick Google search for "fedora hide grub menu" turned up a blog post
or two, an ask.fp.o post, a couple forum threads, and a Stack Exchange
post as the first few results, which makes me believe it's not
currently well explained anywhere in our documentation? Perhaps that
should be fixed, regardless whatever the outcome of this change
discussion is.

Ben Rosser
___
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/DFSPLL3LEHJWOI6J4RJL2OPN4EFEA6MV/

Re: equivalent of Debian config-package?

[Kevin Kofler]

Neal Gompa wrote:
> No such thing currently exists, because an equivalent to `dpkg-divert`
> does not exist in RPM.

You are probably aware of this, but for the other readers of this thread:

File triggers can be (ab)used to do something like that, though it's not as 
easy as running a `dpkg-divert` command, you have to build a dummy package 
with a file trigger that munges the file.

An example of what you can do with file triggers:
https://svn.calcforge.org/viewvc/kannolo/trunk/packages/kannolo-root-unlocker/kannolo-root-unlocker.spec?revision=270=markup

And you can actually even modify packaged files in place with file triggers. 
I opted against doing that in kannolo-root-unlocker because it has some 
drawbacks (produces errors in rpm -V and makes delta RPMs not apply), which 
do however not apply if the files being munged by the file trigger are 
marked %config in the package actually owning them.

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/message/T6K6VAVHHXFFJNOIP3DDAHT4WS4A63X2/

Re: Firefox with native Wayland backend at updates

[Kevin Kofler]

Martin Stransky wrote:
> The Wayland backend is available as an extra desktop entry.

We try hard to avoid messy menus with duplicate entries, and you get away 
with adding an extra desktop entry to an application installed by default on 
almost all Spins, for an experimental option?

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/message/ZUPTLB4TG2YMMACQIDB7NHUUIVWQTCHP/

Re: F29 System Wide Change: Hide the grub menu

[Adam Williamson]

On Thu, 2018-05-31 at 15:58 -0400, Ken Coar wrote:
> At 2018-05-31T02:36, Jason L Tibbitts III irritated the
> Akashic Field to say:
> > 
> > If a user is technical, and our documentation is reasonably good,
> > then they should be able to achieve the level of verbosity they want.
> 
> When you need to get into single-user mode, the documentation
> is probably not to hand. :-)
> 
> How about making this a yes/no installation option?

http://islinuxaboutchoice.com/
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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/GAXJ6MXYTHF3YQ7Q4ZJ4YUJBQXJTVWHI/

Re: F29 System Wide Change: Hide the grub menu

[Chris Murphy]

On Thu, May 31, 2018 at 2:54 PM, Jason L Tibbitts III  wrote:
>> "CM" == Chris Murphy  writes:
>
> CM> I think it's to avoid ambiguity. F8 on one of my computers tells the
> CM> firmware to do a firmware update or some such thing, so I'm going to
> CM> press F8 and maybe get a firmware update menu, or maybe I'll get a
> CM> GRUB menu, depending on my timing. And I think such ambiguity will
> CM> inevitably lead to bad UI/UX.
>
> Unfortunately anything you pick will be ambiguous.

Subjective yes. But not ambiguous.

the "g" key would not be ambiguous. It would be subjective. And I
doubt it conflicts with anything else. But it is a bit obscure decoder
ring. I'm willing to bet the user tries shift, Esc and space bar since
in various eras of GRUB all of those have been trigger keys to reveal
a hidden menu.


>The change under
> discussion mentions adding F8 to the set of keys checked, so that would
> already conflict for you (and already conflicts with Windows, which
> suggests to me that this isn't really much of a conflict).  I have a
> number of machines which use 'Esc' as the key to enter the BIOS, so that
> conflicts with grub now but somehow it has never even occurred to me
> that any conflict exists.
>
> Plus, there's an upside: if you're hammering F11 or F8 or F12 or Esc or
> whatever to try and get into the BIOS, and you miss it, then at least
> you stop in grub instead of going straight into the OS.

Ick.


>
> CM> This is one of those areas were Apple's UX is vastly superior, the
> CM> keyboard shortcuts for firmware and bootloader have been
> CM> standardized for a very long time - at least 20 years, across
> CM> multiple archs and hardware generations and development teams.
>
> If you're going to select just a particular hardware/software
> combination like that, then you could say the same for a number of
> individual laptop or motherboard manufacturers when combined with
> Windows.  Taken as a whole there is no standardization across the
> industry.

It is an imperfect analogy with bias. Nevertheless, even within Dell,
HP or Intel, you get a new product manager, a new firmware OEM, you
eventually get different shortcuts. There's hardly any company in the
tech industry with as much institutional momentum like Apple when it
comes to the user experience - which is one of the reasons why users
of Apple products flip their shit beyond imagination when things
change. And good for them for doing so. These shortcuts as a UI
element have effectively become user domain, even though they are
hidden. They aren't documented within the OS help system, let alone
during boot.

https://support.apple.com/en-us/HT201255


> Anyway, I don't really care what gets chosen here, but I sure would like
> the option to actually configure what keys grub watches instead of just
> having it be 'Esc' and maybe patched to include 'F8'.  Grub seems to be
> so flexible so it seems odd that this bit is hardcoded.

That's a good point.


-- 
Chris Murphy
___
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/4MNXOAZI5WUREQFFRAGZICKXLTWCNAW7/

Re: F29 System Wide Change: Hide the grub menu

[Chris Murphy]

On Thu, May 31, 2018 at 2:43 PM, Andrew Lutomirski  wrote:

>
> More concretely, perhaps plymouth could display such a message on its
> splash screen for as long as its running.  But the message should
> probably be more accurate, along the lines of "Reboot and hold the
> Shift key for more boot options".

I like this general direction. The parts I'm skeptical about is boot
times for some computers are really super short. And some hardware
there is a delay in plymouth even coming up due to kernel messages,
which reduces the time this message would be visible. So it'll take
some spitballing and testing. But I think it's better to give
instructions in plymouth than pretend there's any time to do it in
GRUB.

And also, I think the idea of faster boot times stated for Fedora 29
and Fedora 30 with firmware fast boot support means no USB control
anyway. Yes GRUB itself can initialize USB with its own driver even if
the firmware disables USB. But that'd defeat the point of faster
booting. So on first boot there I'm expecting there isn't any working
USB anyway  - and if that's correct the proper place for messaging is
plymouth.

Another part I'm skeptical of, is the localization of this message in
plymouth based on user's language selection: at installation time? And
how it will be modified? And what languages will be supported? And all
the commensurate testing that indicates. Etc.

-- 
Chris Murphy
___
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/ALKJG3FMBNASDBPWAI7CSDY477FM6CFR/

Re: dnf and deltarpm (Was: Re: Fedora rawhide compose report: 20180529.n.0 changes)

[Samuel Sieb]

On 05/31/2018 02:34 PM, Tomasz Kłoczko wrote:
Nevertheless even f28 GA dnf by default has no enabled use drpm files 
(in dnf-conf package there is no in /etc/dnf/dnf.conf "deltarpm=1" line) 


deltarpm is enabled by default, see "man dnf.conf".
___
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/YPPAGQFZ3T4PORNMASPKUEMFNLFUY7EB/

Re: F29 System Wide Change: Hide the grub menu

[Chris Murphy]

On Thu, May 31, 2018 at 3:15 PM, Till Maas  wrote:
> Hi,
>
> On Thu, May 31, 2018 at 02:30:20PM -0600, Chris Murphy wrote:
>
>> I think it needs to be made specific, unambiguous, and deliberate. Yes
>> this means it is also obscure if you don't know the decoder ring, but
>> worse is when the decoder ring is either random or changing all the
>> time. But for that we get to thank companies that somehow find
>
> Another thing came to my mind: Usually when someone needs to get into
> the menu, it is because something is not working and needs to be fixed.
> This can be a stressful situation, therefore adding extra stress by
> making it hard to fix it instead of making it easy to get help is not
> nice.

And I agree. This feature proposal is full of traps. :-) And that
alone is a reason for high levels of scrutiny and caution. The status
quo might be kinda klunky and ugly and geeky and obscure, but it
pretty much harms no one, and even if confusion is harmful, it's 6
seconds of it.

So as much as I like pretty macOS functionality, I'm not in favor of
half ass pretty that makes life difficult for even more people. If we
want to do it correctly it's a lot more work than is in this proposal.

Right now this proposal is a solution in search of a problem.

-- 
Chris Murphy
___
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/RZ7FZ4APX6ZXUKGQGXQQGB4POBNNSVOC/

Re: F29 System Wide Change: Hide the grub menu

[Chris Murphy]

On Thu, May 31, 2018 at 3:12 PM, Till Maas  wrote:
> On Thu, May 31, 2018 at 02:30:20PM -0600, Chris Murphy wrote:
>> On Thu, May 31, 2018 at 10:00 AM, Jason L Tibbitts III
>
>> > If we're going to patch grub to expand the set of keys it will watch
>> > for, is it possible to just expand the set to encompass all keys?  We
>> > don't really need to make it that hard to find the grub menu, do we?
>>
>> I think it needs to be made specific, unambiguous, and deliberate. Yes
>> this means it is also obscure if you don't know the decoder ring, but
>> worse is when the decoder ring is either random or changing all the
>> time. But for that we get to thank companies that somehow find
>
> Accepting all keys is not random and is also not something that needs to
> be changed all the time. Can you maybe show some scenarios where it is
> actually a problem?

Example 1: From the feature proposal why using F8 "1.2 On some
machines ESC brings up the firmware-setup menu" OK well on one of my
machines F8 brings up some firmware related menu. So that should mean
F8 is squarely out. The point of this change from Esc is to avoid
conflict. Well we have a new conflict with F8. So if the original
logic holds for Esc, then it must hold for F8. If it holds for
neither, provide an argument why it doesn't hold.

Example 2: Instructions say "press any key" and for whatever reason
the GRUB USB keyboard module doesn't actually recognize all keys on an
extended key keyboard. This wouldn't surprise me one bit because
Fedora, out of the box, doesn't recognize the keypad on my extended
key keyboard which also doesn't have a numlock button. And is a
numlock button something GRUB will recognize as "any key"? What about
Fn? Caps lock?

If you say any key it must be literally any key on any keyboard and it
should always work and bring up the intended menu or it's a lie. And
it's not OK to lie to users, except under really arduous
circumstances.

>The instructions for end-users should still be
> clear, nevertheless, e.g. just tell them whatever button to press is the
> best one, but also help the helpless who do not know which button to
> press.

This is not even under discussion in the proposed feature. It's a 1
second timout, it's entirely pointless to have any message. In other
words, you too are advocating substantial modification of the feature
proposal.

Also the feature depends on ‘GRUB_HIDDEN_TIMEOUT_QUIET’ which the GRUB
manual describes as:

‘GRUB_HIDDEN_TIMEOUT_QUIET’
In conjunction with ‘GRUB_HIDDEN_TIMEOUT’, set this to ‘true’ to
suppress the verbose countdown while waiting for a key to be pressed
before displaying the menu.
This option is unset by default, and is deprecated in favour of the
less confusing ‘GRUB_TIMEOUT_STYLE=countdown’.


So it's deprecated and I think it's specious to use deprecated GRUB
features from the outset.


>Also it would be awesome if it was still possible to easily
> reboot to grub after the kernel took over, e.g. from the harddisk
> password screen, GDM login screen and Gnome logout dialog. Then you can
> just make it user-friendly and obvious.

password screen is a plymouth feature request; from what I'm looking
at gdm login and gnome logout dialog both have a restart option which
gets me back to GRUB so I'm not following what different behavior
you're proposing.


-- 
Chris Murphy
___
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/7NK744V5SPMJ74ZB6AWGL7QVU3RKDI6D/

Re: dnf and deltarpm (Was: Re: Fedora rawhide compose report: 20180529.n.0 changes)

[Tomasz Kłoczko]

On 31 May 2018 at 20:59, Stephen Gallagher  wrote:
[..]

> What I wrote does not base on any assumption or guess.
>> And not malice but more likely IMO just plain (not intentional) mistake.
>> Why? Because:
>> a) To handle all Fedora repos dnf does not need depend on deltarpm.
>> Fedora does not provide delta files at all. Nothing here changed recently.
>> In't it?
>>
>
> Fedora has provided deltarpms in the repositories for many years. However,
> it only provides two per RPM: a delta from the one shipped at GA and a
> delta from the most recent one in updates-testing. So if you don't update
> frequently, you'll likely not see many of them.
>

I'm upgrading rawhide on daily bases and rawhide does not have in the tree
any drpm files :)

Just checked on few mirrors usual location of f28 updates
(/pub/linux/dist/fedora/linux/updates/28/Everything/x86_64/drpms) and in
this directory there are at the moment only 56 files from May 31 and
nothing older. So not two drpm per RPM package but only generated files out
of last batch of updates.

Nevertheless even f28 GA dnf by default has no enabled use drpm files
(in dnf-conf
package there is no in /etc/dnf/dnf.conf "deltarpm=1" line) so as long as
someone consciously will not enable use this those files will be never used
(I'm betting that it is ~+99% of all cases).
Because drpm directory provides only drpm files out of last batch of
updates I'm guessing that dnf in case other updates will fallback to use
regular packages from updates directory), and this is no one is screaming
that something is wrong with drpm directory content. Am I correct? if not
drpm/ content already may be broken (? .. but if ~no one is using this ->
no one care (?))

Ergo: using use weak dependency between dnf and deltarpm looks like it is
100% correct (Q.E.D.)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
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/F77UBAZVNKSGPYDSUTPGE3PKQLDS4UB4/

Re: F29 System Wide Change: Hide the grub menu

[Till Maas]

Hi,

On Thu, May 31, 2018 at 02:30:20PM -0600, Chris Murphy wrote:

> I think it needs to be made specific, unambiguous, and deliberate. Yes
> this means it is also obscure if you don't know the decoder ring, but
> worse is when the decoder ring is either random or changing all the
> time. But for that we get to thank companies that somehow find

Another thing came to my mind: Usually when someone needs to get into
the menu, it is because something is not working and needs to be fixed.
This can be a stressful situation, therefore adding extra stress by
making it hard to fix it instead of making it easy to get help is not
nice.

Kind regards
Till
___
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/AE2H6GOO3NPVG4XTUKMFKRPMJAOY4NSR/

Re: F29 System Wide Change: Hide the grub menu

[Till Maas]

On Thu, May 31, 2018 at 02:30:20PM -0600, Chris Murphy wrote:
> On Thu, May 31, 2018 at 10:00 AM, Jason L Tibbitts III

> > If we're going to patch grub to expand the set of keys it will watch
> > for, is it possible to just expand the set to encompass all keys?  We
> > don't really need to make it that hard to find the grub menu, do we?
> 
> I think it needs to be made specific, unambiguous, and deliberate. Yes
> this means it is also obscure if you don't know the decoder ring, but
> worse is when the decoder ring is either random or changing all the
> time. But for that we get to thank companies that somehow find

Accepting all keys is not random and is also not something that needs to
be changed all the time. Can you maybe show some scenarios where it is
actually a problem? The instructions for end-users should still be
clear, nevertheless, e.g. just tell them whatever button to press is the
best one, but also help the helpless who do not know which button to
press. Also it would be awesome if it was still possible to easily
reboot to grub after the kernel took over, e.g. from the harddisk
password screen, GDM login screen and Gnome logout dialog. Then you can
just make it user-friendly and obvious.

Kind regards
Till
___
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/62DFVUZR754TURBXPJWO4K556VC4UKAB/

Re: F29 System Wide Change: Hide the grub menu

[Chris Murphy]

On Thu, May 31, 2018 at 1:58 PM, Ken Coar  wrote:
> At 2018-05-31T02:36, Jason L Tibbitts III irritated the
> Akashic Field to say:
>>
>> If a user is technical, and our documentation is reasonably good,
>> then they should be able to achieve the level of verbosity they want.
>
> When you need to get into single-user mode, the documentation
> is probably not to hand. :-)
>
> How about making this a yes/no installation option?  With
> a default of not changing the current behaviour?
>
> "Do you want to always see the Grub menu, even when you
> only have a single kernel installed on your bloody machine?
> Choosing 'Y' will retain the behaviour exhibited by prior
> versions of Fedora. [Yn]" :-)

No, we need to some to some kind of consensus. Making the already
overly complicated installer more complicated is not a good plan for
either users or testers. And contra snark for your snark: that's
pretty adversarial and thus shitty UI/UX wording,  that will at best
give translation and documentation folks a headache, and
simultaneously gives a majority of Fedora users no f'n clue what
behavior is even under discussion. What's GRUB? What's a single
kernel? My prior Fedora had behavior Q because 4 years ago I modified
it, forgot about that modification, and have never done a clean
install since then, so my idea of "default" differs from the distro
installation default.

So yeah - no, no, and no.

I wonder what percentage of users this change applies to. Most users I
think are multibooting Workstation. And Atomic, Cloud, and Server
products will all continue to need GRUB menu visibility by default.

I see the change as probably benefiting a few and harming a few, and
at least on the surface it appears to be a tie. And therefore I'd say
it's not compelling enough of a change.

-- 
Chris Murphy
___
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/5U5EHMVHNDSUT2KHDDFYXFLVELQG6ZOI/

Re: F29 System Wide Change: Hide the grub menu

[Jason L Tibbitts III]

> "CM" == Chris Murphy  writes:

CM> I think it's to avoid ambiguity. F8 on one of my computers tells the
CM> firmware to do a firmware update or some such thing, so I'm going to
CM> press F8 and maybe get a firmware update menu, or maybe I'll get a
CM> GRUB menu, depending on my timing. And I think such ambiguity will
CM> inevitably lead to bad UI/UX.

Unfortunately anything you pick will be ambiguous.  The change under
discussion mentions adding F8 to the set of keys checked, so that would
already conflict for you (and already conflicts with Windows, which
suggests to me that this isn't really much of a conflict).  I have a
number of machines which use 'Esc' as the key to enter the BIOS, so that
conflicts with grub now but somehow it has never even occurred to me
that any conflict exists.

Plus, there's an upside: if you're hammering F11 or F8 or F12 or Esc or
whatever to try and get into the BIOS, and you miss it, then at least
you stop in grub instead of going straight into the OS.

CM> This is one of those areas were Apple's UX is vastly superior, the
CM> keyboard shortcuts for firmware and bootloader have been
CM> standardized for a very long time - at least 20 years, across
CM> multiple archs and hardware generations and development teams.

If you're going to select just a particular hardware/software
combination like that, then you could say the same for a number of
individual laptop or motherboard manufacturers when combined with
Windows.  Taken as a whole there is no standardization across the
industry.

CM> I think it needs to be made specific, unambiguous, and deliberate.

And... there's nothing that satisfies those to my knowledge.  The only
thing I see as remotely unambiguous is "press any key to enter the grub
menu".

Anyway, I don't really care what gets chosen here, but I sure would like
the option to actually configure what keys grub watches instead of just
having it be 'Esc' and maybe patched to include 'F8'.  Grub seems to be
so flexible so it seems odd that this bit is hardcoded.

 - J<
___
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/CP2GM5JAS7ESGOF7O3XPMG4BKXQRA7EH/

Re: Unified Unison package (again)

[Till Maas]

Hi,

On Thu, May 31, 2018 at 09:13:09AM -0400, Stephen Gallagher wrote:
> On Thu, May 31, 2018 at 9:07 AM Till Maas  wrote:

> > Yes and yes, otherwise one could not synchronise between older and newer
> > Fedoras.
> >
> >
> If they needed to sync between older systems, couldn't the newer ones just
> all standardize on the oldest, most-compatible one?

Then you would at least have to change all systems at once, e.g. once
you want to upgrade your unison server, you will have to upgrade/change
all clients at the same time, which is something that I would not like.
I use it with different notebooks and would like to not have to update
them all at the same time.

Kind regards
Till
___
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/2WDDA3M5YZCTKF7N2ANUVZCSSRKFLRCX/

Re: Unified Unison package (again)

[Matthew Miller]

On Thu, May 31, 2018 at 08:47:45PM +0100, Richard W.M. Jones wrote:
> I wonder are there any other single RPM modules?  I'm only
> used to large multi-package modules like virt.

Since "make a module of it!" is our path for getting from stream
branches to actually released, I'm going to convert some of my packages
into modules so that I only have one stream to worry about across all
current Fedora releases (and hopefully soon, EPEL).

-- 
Matthew Miller

Fedora Project Leader
___
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/R3GSXOFGVSVEMZT5ZBVWQ7S6IKK5IUYI/

Re: F29 System Wide Change: Hide the grub menu

[Andrew Lutomirski]

On Thu, May 31, 2018 at 1:26 PM, R P Herrold  wrote:
>
> I think it was a fair question which was raised about the size
> of the audience being sought to be catered to, vs the mass of
> users of Fedoraproject code, and their 'least astonishment'
> and loss of acquired knowledge as to use
>
> If there are, oh, say, twelve people in the world that
> actually care about instantaneous GUI boots in Fedora, it is a
> waste of time to mess with this thread
>
>
> but to the most recent point raised about 'modifier keys'.  I
> recall doing this back in DOS days with a third-party tool
> that permitted 'BAT files' to query for Shift, Alt, and Ctrl
> key states, and to build boolean decision trees:
>
> On Thu, 31 May 2018, Andrew Lutomirski wrote:
>
>> If the protocol were that the boot menu would be shown if
>> any key at all were held down, then we wouldn't need a 1
>> second delay.
>
> or, perhaps, better still and less complex as in needing to
> suppress a boot menu, a message at the bottom of the GUI
> screen from its first appearance and for ten seconds or so:
> Hold either Shift key for more boot options

More concretely, perhaps plymouth could display such a message on its
splash screen for as long as its running.  But the message should
probably be more accurate, along the lines of "Reboot and hold the
Shift key for more boot options".
___
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/HQ5BAPZVCGLZ77ONMIWJASXL7WKAYIUW/

Re: F29 System Wide Change: Hide the grub menu

[stan]

On Thu, 31 May 2018 14:36:39 -0500
Jason L Tibbitts III  wrote:

> that they don't want to see the stuff and indeed, 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.  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've been thinking about this, and see an opportunity for
monetization.  Instead of the user staring at the splash screen until
the login comes up, we could sell advertising.  Static jpgs.  Facebook
or Google would probably be willing to throw a few hundred thousand if
we did that to have their ad flash instead of the splash screen.  Or
even Microsoft and Mac might want to advertise their OSs to a possibly
receptive audience.  If that doesn't fly, maybe RedHat would be willing
to advertise their server OS, or Fedora could put helpful hints up,
like pointing to the user list, or how to contribute, or where to find
documentation.  Maybe all of the above, randomly selected each boot.

Paid advertisements could contribute to Fedora development.  Pizza at
the development conferences, or more hardware for build and test.  I
have to confess I'm more comfortable suggesting this because I'd never
see such ads.  :-)

Tongue-in-cheek, sort of.  Hey, why not, everyone else monetizes
everything.
___
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/FK7WMXWNIDZ73ZHSE6LWTXRD4IXNGTFP/

Re: Firefox with native Wayland backend at updates

[Simo Sorce]

On Wed, 2018-05-30 at 09:31 +0200, Tomas Popela wrote:
> On Tue, May 29, 2018 at 8:23 PM, Simo Sorce  wrote:
> > 
> > Is screen sharing [at least of its own window(s)] supposed to work ?
> > If I share the screen with a screen sharing app all I get to send is a
> > black background, sometimes with the mouse cursor visibile on it.
> > 
> 
> No, that won't work because there's only X11 support in WebRTC. But the
> desktop team is working on bringing the Pipewire support to it and once
> it's finished then it will work

Ok thanks, then I'll stay on X11 till then, screen sharing is something
I depend on for work.
Do you know if it will also be possible to share, individual, other
applications when pipewire support is enabled ?

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
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/N2WF7IFWTXP46F372W7HYJT4V3OAWJ65/

Re: F29 System Wide Change: Hide the grub menu

[Chris Murphy]

On Thu, May 31, 2018 at 10:00 AM, Jason L Tibbitts III
 wrote:
>> "JK" == Jan Kurik  writes:
>
> JK> 1. Add patches to grub to also make pressing F8 show the menu
>
> One thing I've never really understood is the reason for using such a
> small set of keys to interrupt the boot process.  I seem to recall that
> in older versions (perhaps pre-grub2) the space bar or the cursor keys
> worked.  I also recall at some point that you could just hold down the
> shift key.  More recently I actually thought something was broken
> because I simply couldn't find the magic key (only later finding out
> that it had at some point been limited to just 'Esc').

I think it's to avoid ambiguity. F8 on one of my computers tells the
firmware to do a firmware update or some such thing, so I'm going to
press F8 and maybe get a firmware update menu, or maybe I'll get a
GRUB menu, depending on my timing. And I think such ambiguity will
inevitably lead to bad UI/UX.

I have wondered why UEFI never got around to standardizing firmware
keyboard shortcuts, or whether the OEM firmware vendors actively
lobbied to not standardize.

This is one of those areas were Apple's UX is vastly superior, the
keyboard shortcuts for firmware and bootloader have been standardized
for a very long time - at least 20 years, across multiple archs and
hardware generations and development teams.


> If we're going to patch grub to expand the set of keys it will watch
> for, is it possible to just expand the set to encompass all keys?  We
> don't really need to make it that hard to find the grub menu, do we?

I think it needs to be made specific, unambiguous, and deliberate. Yes
this means it is also obscure if you don't know the decoder ring, but
worse is when the decoder ring is either random or changing all the
time. But for that we get to thank companies that somehow find
standardization in this area to be unimportant or offensive - I'm not
really sure where they're at with it but they can literally do
anything they want and yet they aren't doing this.


-- 
Chris Murphy
___
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/LI5AXFGEEPU3RQRRXCNQMCMUBBWHPTM3/

Re: F29 System Wide Change: Hide the grub menu

[R P Herrold]

I think it was a fair question which was raised about the size 
of the audience being sought to be catered to, vs the mass of 
users of Fedoraproject code, and their 'least astonishment' 
and loss of acquired knowledge as to use

If there are, oh, say, twelve people in the world that 
actually care about instantaneous GUI boots in Fedora, it is a 
waste of time to mess with this thread


but to the most recent point raised about 'modifier keys'.  I 
recall doing this back in DOS days with a third-party tool 
that permitted 'BAT files' to query for Shift, Alt, and Ctrl 
key states, and to build boolean decision trees:

On Thu, 31 May 2018, Andrew Lutomirski wrote:

> If the protocol were that the boot menu would be shown if 
> any key at all were held down, then we wouldn't need a 1 
> second delay.

or, perhaps, better still and less complex as in needing to 
suppress a boot menu, a message at the bottom of the GUI 
screen from its first appearance and for ten seconds or so:
Hold either Shift key for more boot options

so that a person could be habituated to holding a 'harmless' 
key. Harmless, in the sense that it does not fill and over-run 
a key-press buffer and start beeping at the holder

I speak having personal setup options of:

15 sec timeout at the grub options menu 

with plymouth graphical stuff, rhgb, and quiet 
disabled

always booting to a non-GUI console
why: multi-user.target for something formerly
though of as 'single user', although with 
multiple PTYs ?? 

with a 640x480 console

which is NOT cleared away

to support the fact that I am almost always remote and on KVM 
devices of varying resolutions, and so favoring a 'least 
common denominator' as to capabilities

That last (preserving the TUI boot screen was tricky to find 
docoed

Use:
 # systemctl edit getty@tty1

and add:

#
[Service]
TTYVTDisallocate=no
#

as the description for the service

-- Russ herrold
___
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/BNQURFE2BWBLLII47V7DN7JTUNSTVCX3/

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

[Jason L Tibbitts III]

> "AL" == Andrew Lutomirski  writes:

AL> If the protocol were that the boot menu would be shown if any key at
AL> all were held down, then we wouldn't need a 1 second delay.

For some reason I also recall just holding shift down to get into grub,
and doing searches on that seems to imply that it's supposed to work
with the default grub setups in some distros.  I see that grub does have
a keystatus command (which can check for shift, ctrl or alt) but it
doesn't appear that our configuration uses it at all.

 - J<
___
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/G7MN4WKPRNIHKN3Y473EVB4FR23CCGOY/

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

[DJ Delorie]

Chris Adams  writes:
> If I know I want the menu (say I need to boot single-user to fix
> something), how would I do that in this setup?

Ah, that reminds me of the good old days of looking up on the internet
which of the many keys on the keyboard gets me into the BIOS setup
menu...
___
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/FNNQU6KRGDUSF5OMKXK3JRBEUYG67JMT/

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

[Chuck Anderson]

On Thu, May 31, 2018 at 12:09:45PM -0500, Chris Adams wrote:
> Once upon a time, Hans de Goede  said:
> > On 31-05-18 15:08, Chris Adams wrote:
> > >Once upon a time, Hans de Goede  said:
> > >>And for F30, single OS install we get:
> > >>
> > >>1) grub menu not shown, 0 second timeout, no way to get to the menu
> > >>2) grub menu shown with 5 sec timeout after a failed boot
> > >
> > >If I know I want the menu (say I need to boot single-user to fix
> > >something), how would I do that in this setup?
> > 
> > Hopefully what ever you want to fix will count as a "failed boot"
> > if it requires single user mode.
> 
> Hmm... not really.  For example (just off the top of my head): lost root
> password.  Without it, you won't be able to set any "next boot is
> special" option, so resetting root's password would now require rescue
> media.
> 
> I'd say I'm against this part of your proposal.  I understand the
> reasoning, but it just seems like too much restriction to shave off a
> small amount of time.  You mentioned it "could take several seconds" for
> EFI to initialize USB, but what is the normal time, for a typical
> desktop or notebook with just a keyboard and mouse attached?

I agree.  Another use case is that failed graphics initialization may
not count as "failed boot". 
___
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/CWA5Z3IYQQURAIFFNNCLE5TXXSGXRC5E/

Re: F29 System Wide Change: Hide the grub menu

[Andrew Lutomirski]

On Thu, May 31, 2018 at 9:00 AM, Jason L Tibbitts III  wrote:
>> "JK" == Jan Kurik  writes:
>
> JK> 1. Add patches to grub to also make pressing F8 show the menu
>
> One thing I've never really understood is the reason for using such a
> small set of keys to interrupt the boot process.  I seem to recall that
> in older versions (perhaps pre-grub2) the space bar or the cursor keys
> worked.  I also recall at some point that you could just hold down the
> shift key.  More recently I actually thought something was broken
> because I simply couldn't find the magic key (only later finding out
> that it had at some point been limited to just 'Esc').
>
> If we're going to patch grub to expand the set of keys it will watch
> for, is it possible to just expand the set to encompass all keys?  We
> don't really need to make it that hard to find the grub menu, do we?

Yes, please, and for more than just ease of use.  Adding an
intentional 1-second delay to the boot process to give the user the
opportunity to press escape is disappointing.  If the protocol were
that the boot menu would be shown if any key at all were held down,
then we wouldn't need a 1 second delay.

--Andy
___
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/VEWAONS5D6BP54H637IHOKFXXVOF2R4C/

Re: dnf and deltarpm (Was: Re: Fedora rawhide compose report: 20180529.n.0 changes)

[Stephen Gallagher]

On Thu, May 31, 2018 at 3:41 PM Tomasz Kłoczko 
wrote:

> On 31 May 2018 at 18:40, Matthew Miller  wrote:
>
>> On Thu, May 31, 2018 at 06:24:49PM +0100, Tomasz Kłoczko wrote:
>> > >   * Fri May 25 2018 Martin Hatina  - 2.7.5-13
>> > >   - Rebase to dnf from dnf-2-modularity-6 release.
>> > It is yet another hidden change not listed in above.
>>
>> S, rather than assuming malice, since the change isn't noted, I'd
>> guess that somehow the recommends got inadvertently reverted as part of
>> the rebase.
>>
>
> What I wrote does not base on any assumption or guess.
> And not malice but more likely IMO just plain (not intentional) mistake.
> Why? Because:
> a) To handle all Fedora repos dnf does not need depend on deltarpm. Fedora
> does not provide delta files at all. Nothing here changed recently. In't it?
>

Fedora has provided deltarpms in the repositories for many years. However,
it only provides two per RPM: a delta from the one shipped at GA and a
delta from the most recent one in updates-testing. So if you don't update
frequently, you'll likely not see many of them.
___
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/X7DO27YELOMM7QU3DVFYVL5SQ6JWEOAR/

Re: F29 System Wide Change: Hide the grub menu

[Ken Coar]

At 2018-05-31T02:36, Jason L Tibbitts III irritated the
Akashic Field to say:
>
> If a user is technical, and our documentation is reasonably good,
> then they should be able to achieve the level of verbosity they want.

When you need to get into single-user mode, the documentation
is probably not to hand. :-)

How about making this a yes/no installation option?  With
a default of not changing the current behaviour?

"Do you want to always see the Grub menu, even when you
only have a single kernel installed on your bloody machine?
Choosing 'Y' will retain the behaviour exhibited by prior
versions of Fedora. [Yn]" :-)
-- 
#kenB-|}

Ken, Baron Coar
RHCA, RHCVA, Sanagendamgagwedweinini
Red Hat IT Infrastructure
___
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/ADZQ2DLLBSNBA43KAHOV35WERDAFO3IL/

Re: Unified Unison package (again)

[Stephen Gallagher]

On Thu, May 31, 2018 at 3:48 PM Richard W.M. Jones 
wrote:

>
> I wonder are there any other single RPM modules?  I'm only
> used to large multi-package modules like virt.
>
>
Node.js's 8.x stream, for example:

https://src.fedoraproject.org/modules/nodejs/blob/8/f/nodejs.yaml
___
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/VVCPE3TOILPEKFFIPEKP35HC43G4LBNQ/

Re: Unified Unison package (again)

[Richard W.M. Jones]

I wonder are there any other single RPM modules?  I'm only
used to large multi-package modules like virt.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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/4Y5OVBKH5RSLP4F3G7SVG46UQMBPUJSN/

Re: dnf and deltarpm (Was: Re: Fedora rawhide compose report: 20180529.n.0 changes)

[Tomasz Kłoczko]

On 31 May 2018 at 18:40, Matthew Miller  wrote:

> On Thu, May 31, 2018 at 06:24:49PM +0100, Tomasz Kłoczko wrote:
> > >   * Fri May 25 2018 Martin Hatina  - 2.7.5-13
> > >   - Rebase to dnf from dnf-2-modularity-6 release.
> > It is yet another hidden change not listed in above.
>
> S, rather than assuming malice, since the change isn't noted, I'd
> guess that somehow the recommends got inadvertently reverted as part of
> the rebase.
>

What I wrote does not base on any assumption or guess.
And not malice but more likely IMO just plain (not intentional) mistake.
Why? Because:
a) To handle all Fedora repos dnf does not need depend on deltarpm. Fedora
does not provide delta files at all. Nothing here changed recently. In't it?
b) There is no anywhere single word of comment about why weak dependency
has been suddenly replaced by fixed one. This recent change is kind of
rollback of the Feb change:

* Thu Feb 08 2018 Igor Gnatenko  - 2.7.5-7
- Demote deltarpm to weak dependencies

IMO it would be even better if during dnf code rewrite to other language
like C/C++ (which start has been announced some time ago) handle of
deltarpm files would be possible over kind of optional loadable module
leaving dnf core code as small as it is only possible.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
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/OXCEBRL2J6UUBOYULI7MTATAYZDYU7HS/

Re: F29 System Wide Change: Hide the grub menu

[Jason L Tibbitts III]

> "JF" == John Florian  writes:

JF> Does Fedora really have that large of non-technical audience?

It's an interesting question, but it seems to me that the answer doesn't
really matter.  If they're non-technical, the assumption is that they
don't want to see the stuff and indeed, 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.  I am pretty sure that's the end
goal here and hiding the grub menu by default is just a step in that
direction.

If a user is technical, and our documentation is reasonably good, then
they should be able to achieve the level of verbosity they want.

So in the end, it doesn't seem to matter much how technical the audience
is.  What appear to matter most is how much fuss people will make about
having to adapt to (and, if they want, revert) a changed default.

Personally, I don't much care either way because I already have to
configure systems to get rid of the annoying and useless (in my
environment) grub menu.  So for me it would just be one task I can
remove from my ansible playbooks.  But if we always have that menu
appearing then there won't be much impetus to get that nice, smooth boot
experience because nobody who takes the defaults will see it.  And yes,
such things do matter to some people.

 - J<
___
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/AC34RG5OGEHXWBMXP5PZHFLCAXJAZK4F/

Re: Looking up module information via Koji

[Owen Taylor]

[ Broadening the audience to include devel@lists.fedoraproject.org ]

Anybody have thoughts about my question below? some examples of places
which will need logic like this to replace PDC usage:

 ODCS
Resolve a module name:stream to a particular build, and do dependency
expansion
 fedmod
   Get the flatpak-runtime modulemd to find what packages aren't in the
runtime and need to be bundled
atomic-reactor
   Load the modulemd for particular module builds to get profile
information and figure out what to install in a container
 flatpak-module-tools
   Load modulemd and do dependency expansion to build a container locally
 rpkg
Load the modulemd  module we are building into a flatpak to find what
runtime it is using, and hence the right build target

Thanks!
Owen


On Mon, May 21, 2018 at 1:29 PM, Owen Taylor  wrote:

> My understanding is that with the planned retirement of the PDC:
>
>  https://lists.fedoraproject.org/archives/list/infrastructure@lists.
> fedoraproject.org/thread/JHKHWYU5XK7H2P2QZZCCQR4ZRCTY3OSB/
>
> Querying for module information should be done using the MBS and/or Koji
> APIs.
>
> Various code that I maintain (in OSBS, fedmod, and random tooling) wants
> to do module build lookups - different variations of  "look up the modulemd
> for latest build of a NAME:STREAM[:VERSION]". Variations generally being
> exactly what "latest" means here.
>
> The code generally already is using Koji and the MBS api is quite limited,
> so I've chosen to do the lookups via Koji.
>
>  https://fishsoup.net/misc/get-module-builds
>
> Is a test tool that incorporates most of the capability that I needed
> across my uses. It's distinctly more than a couple of lines of code - I can
> cut-and-paste it for now, but what's the right long-term home? Is there a
> simpler way?
>
> My best idea right now is that if the 'base_version' and'status' part of
> my code was simplified to simply be "tag" and avoid reliance on the tag
> structure of Fedora, then this might make a reasonable addition to the Koji
> CLI and API - there are some things that using raw tags for the query makes
> trickier, but it's probably workable.
>
> Thanks for any input!
> Owen
>
>
___
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/DXJEL6SJZH4XQQBBX7Z3RAX33S6B6OZB/

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

[Björn Persson]

Hans de Goede wrote:
> On 31-05-18 15:20, Robert Marcano wrote:
> > What is the definition of a successful boot? I ask because a machine could 
> > boot perfectly, and when you try to interact with it on the login screen, 
> > bugs on the display driver can change the screen to garbage (I have seen 
> > this kind on bug long time ago), or lockup. So, the user will be unable to 
> > activate any kind of restart with menu enabled in order to try an older 
> > kernel, or boot to rescue mode.
> > 
> > I think instead of only detecting a successful boot, a machine that wasn't 
> > properly shutdown should enable the menu  
> 
> A broken install may still shutdown properly after the using pressing the 
> power-button and/or
> trying ctrl+alt+del.
> 
> But this is an interesting suggestion, I think we should track both 
> separately,
> so successful shutdown and successful boot and show the menu if either one is
> not true. That should make the chance of not being able to get the menu a lot
> smaller.

This is starting to sound rather complex, and complex code is prone to
bugs. I want my bootloader as simple and straightforward as possible to
minimize the risk of problems. I would hate to run into some bug that
renders the system unusable, and then find that I can't do anything
about it because a separate bug causes Grub to not display the boot
menu.

Björn Persson


pgpn63RGL_xaV.pgp
Description: OpenPGP digital signatur
___
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/3BDC5QQWQQGR3VIIXJO6TNXUZF7FXUSU/

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

[Ian Pilcher]

On 05/31/2018 07:25 AM, Hans de Goede wrote:


So for F29, single OS install we get:

1) grub menu hidden by default with a 1 second timeout to press ESC
or F8 to show it
2) grub menu shown with 5 sec timeout after a failed boot


5 seconds seems like an awfully short timeout after a failed boot.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

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

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/

Fedora Rawhide-20180531.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/137 (x86_64), 2/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20180530.n.0):

ID: 243983  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/243983

Old failures (same test failed in Rawhide-20180530.n.0):

ID: 243985  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/243985
ID: 243986  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/243986
ID: 244001  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/244001
ID: 244042  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/244042

Soft failed openQA tests: 7/137 (x86_64), 2/24 (i386)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20180530.n.0):

ID: 243989  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/243989

Old soft failures (same test soft failed in Rawhide-20180530.n.0):

ID: 243962  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/243962
ID: 243963  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/243963
ID: 243964  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/243964
ID: 244016  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/244016
ID: 244059  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/244059
ID: 244064  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/244064
ID: 244067  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/244067
ID: 244068  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/244068

Passed openQA tests: 128/137 (x86_64), 20/24 (i386)

New passes (same test did not pass in Rawhide-20180530.n.0):

ID: 243968  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/243968
ID: 243970  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/243970

Skipped openQA tests: 1 of 163

Installed system changes in test x86_64 Server-boot-iso install_default: 
Used mem changed from 197 MiB to 167 MiB
Previous test data: https://openqa.fedoraproject.org/tests/243491#downloads
Current test data: https://openqa.fedoraproject.org/tests/243940#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
Used mem changed from 201 MiB to 171 MiB
Previous test data: https://openqa.fedoraproject.org/tests/243492#downloads
Current test data: https://openqa.fedoraproject.org/tests/243941#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 1.09 to 1.38
Used mem changed from 167 MiB to 196 MiB
Previous test data: https://openqa.fedoraproject.org/tests/243495#downloads
Current test data: https://openqa.fedoraproject.org/tests/243944#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 1.15 to 1.50
Used mem changed from 171 MiB to 200 MiB
Previous test data: https://openqa.fedoraproject.org/tests/243497#downloads
Current test data: https://openqa.fedoraproject.org/tests/243946#downloads

Installed system changes in test i386 Server-dvd-iso install_default: 
Used mem changed from 116 MiB to 129 MiB
Previous test data: https://openqa.fedoraproject.org/tests/243515#downloads
Current test data: https://openqa.fedoraproject.org/tests/243964#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
Used mem changed from 157 MiB to 129 MiB
Previous test data: https://openqa.fedoraproject.org/tests/243516#downloads
Current test data: https://openqa.fedoraproject.org/tests/243965#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
Used mem changed from 161 MiB to 133 MiB
Previous test data: https://openqa.fedoraproject.org/tests/243517#downloads
Current test data: https://openqa.fedoraproject.org/tests/243966#downloads

Installed system changes in test i386 Everything-boot-iso install_default: 
System load changed from 0.34 to 0.65
Previous test data: https://openqa.fedoraproject.org/tests/243518#downloads
Current test data: https://openqa.fedoraproject.org/tests/243967#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 2.14 to 2.37
Average CPU usage changed from 7.58571429 to 22.99523810
Used swap changed from 1 MiB to 5 MiB
Previous 

Re: dnf and deltarpm (Was: Re: Fedora rawhide compose report: 20180529.n.0 changes)

[Matthew Miller]

On Thu, May 31, 2018 at 06:24:49PM +0100, Tomasz Kłoczko wrote:
> >   * Fri May 25 2018 Martin Hatina  - 2.7.5-13
> >   - Rebase to dnf from dnf-2-modularity-6 release.
> It is yet another hidden change not listed in above.

S, rather than assuming malice, since the change isn't noted, I'd
guess that somehow the recommends got inadvertently reverted as part of
the rebase.

> Because today has been published next dnf release I'm going to repeating
> the bugzilla ticket question about deltrpm question but this time
> publically.

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

A bugzilla title "dnf and deltarpm" does not describe the problem well.
I'd suggest, instead, something like "deltrpm (inadvertently?) added
back as strong 'Requires' rather than 'Recommends'".


-- 
Matthew Miller

Fedora Project Leader
___
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/6PN62NETAXWOYYZW2AZ3I5ZGBHLGJQK4/

Re: Unified Unison package (again)

[Stephen Gallagher]

On Thu, May 31, 2018 at 1:33 PM Stephen Gallagher 
wrote:

> On Thu, May 31, 2018 at 9:49 AM Richard W.M. Jones 
> wrote:
>
>> On Thu, May 31, 2018 at 08:53:25AM -0400, Stephen Gallagher wrote:
>> > Are these packages parallel-installable (and do they need to be?)
>>
>> In theory, although practically it probably wouldn't be the end of the
>> world if they were not parallel installable (it's my understanding
>> that the current module proposal does not allow parallel installation
>> of modules).
>>
>>
> Correct, modules right now allow parallel-*availability*, but only one
> stream can be installed at a time.
>
>
>> The scenario were parallel installation would be useful is something
>> like you want to synch between *three* machines with mutually
>> incompatible versions of unison, and the Fedora machine in the middle
>> needing both.  It's pretty obscure.
>>
>>
> Yeah, that seems like the sort of thing we'd probably want to discourage
> (or if we can't discourage it, solve it by running unison in a container).
>
>
>
>> > It seems
>> > to me like this would be a FAR better solution as a module. You just
>> have
>> > branches for the major/minor releases and then ship module streams for
>> each
>> > one. They can be built and updated independently (rather than rebuilding
>> > all of them each time any of them releases an update).
>> >
>> > I can help you with this, if it's an approach you want to take.
>>
>> It's worth looking at certainly.  Could you look at these two files
>> and tell me how they could be turned into a module?  If you look at
>> them side by side you can see they are very similar, probably one
>> derived from the other at some point in the past:
>>
>> https://src.fedoraproject.org/rpms/unison213/blob/master/f/unison213.spec
>> https://src.fedoraproject.org/rpms/unison227/blob/master/f/unison227.spec
>>
>> The cliffs notes version:
> * Resurrect the 'unison' (unversioned) package name.
> * Run `fedpkg request-branch 2.13 --sl="rawhide:2020-06-01"`
> * Run `fedpkg request-branch 2.17 --sl="rawhide:2020-06-01"`
> * Switch to the 2.13 branch
> * Copy the unison213 spec in there as unison.spec and drop the pieces that
> change the paths to include "213".
> * Push the 2.13 branch to dist-git
> * `fedpkg clone modules/unison` (this will have been created as part of
> request-branch above unless you pass --no-auto-module)
> * Switch to the 2.13 branch (also auto-created)
> * Create the modulemd file. This can be done easily with 'fedmod'
> (currently in updates-testing).
> - `fedmod fetch-metadata` (takes a couple minutes the first time)
> - `fedmod rpm2module unison213 > unison.yaml` (Filename must match the
> dist-git module name plus .yaml, similar to how RPMs have to match the
> specfile name)
> - Fix the places where the generated file includes "213" (this step is
> unique to your situation; others reading this will not need to do this)
> - Add `ref: 2.13` under "buildorder" in the YAML so it knows which branch
> to pull from.
> - If you don't want to build the module on F28, change build and runtime
> requires from
> platform: [ ]
> to
> platform: [-f28]
> (You could also use `platform: [f29]`, but this wouldn't automatically
> pick up F30 when F29 branches).
> * Push this branch to dist-git and run `fedpkg module-build`
> * Submit the module to Bodhi for F28 if desired. F29/Rawhide will appear
> automatically in the modular repos at the next Rawhide compose.
>
> * Repeat for the 2.27 branch
>
>
> Optional (recommended) step: submit a PR to
> https://pagure.io/releng/fedora-module-defaults to have one of the
> streams made "default" so that `dnf install unison` will Just Work without
> having to know about modules. Other streams can be installed with `dnf
> install @unison:2.13
>

Accidentally hit send.

This and other streams can be installed with `dnf install @unison:2.13` or
`dnf module install unison:2.13`

And I would have inlined this above, but you will also want to add a
Profile: section to the YAML with at least a profile named 'default' so DNF
will know what packages to install if you use the module syntax that I
showed for "other streams".

See
https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L144
for
an explanation of profiles (and the rest of that file for details on the
format in general, though most of what you'll need will have been added by
fedmod)
___
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/6P3ANF2SGXZDJB6MCZB7GD3QVILGNUWC/

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

[stan]

On Thu, 31 May 2018 17:43:13 +0200
Hans de Goede  wrote:

> TL;DR: Yes you will still be able to do this with a simple 1 time
> configfile change.

Thanks, seems you have all your ducks in a row.
___
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/RHRND4FRO6W5APYWKERRCGTBLOFSUE2C/

Re: Unified Unison package (again)

[Stephen Gallagher]

On Thu, May 31, 2018 at 9:49 AM Richard W.M. Jones 
wrote:

> On Thu, May 31, 2018 at 08:53:25AM -0400, Stephen Gallagher wrote:
> > Are these packages parallel-installable (and do they need to be?)
>
> In theory, although practically it probably wouldn't be the end of the
> world if they were not parallel installable (it's my understanding
> that the current module proposal does not allow parallel installation
> of modules).
>
>
Correct, modules right now allow parallel-*availability*, but only one
stream can be installed at a time.


> The scenario were parallel installation would be useful is something
> like you want to synch between *three* machines with mutually
> incompatible versions of unison, and the Fedora machine in the middle
> needing both.  It's pretty obscure.
>
>
Yeah, that seems like the sort of thing we'd probably want to discourage
(or if we can't discourage it, solve it by running unison in a container).



> > It seems
> > to me like this would be a FAR better solution as a module. You just have
> > branches for the major/minor releases and then ship module streams for
> each
> > one. They can be built and updated independently (rather than rebuilding
> > all of them each time any of them releases an update).
> >
> > I can help you with this, if it's an approach you want to take.
>
> It's worth looking at certainly.  Could you look at these two files
> and tell me how they could be turned into a module?  If you look at
> them side by side you can see they are very similar, probably one
> derived from the other at some point in the past:
>
> https://src.fedoraproject.org/rpms/unison213/blob/master/f/unison213.spec
> https://src.fedoraproject.org/rpms/unison227/blob/master/f/unison227.spec
>
> The cliffs notes version:
* Resurrect the 'unison' (unversioned) package name.
* Run `fedpkg request-branch 2.13 --sl="rawhide:2020-06-01"`
* Run `fedpkg request-branch 2.17 --sl="rawhide:2020-06-01"`
* Switch to the 2.13 branch
* Copy the unison213 spec in there as unison.spec and drop the pieces that
change the paths to include "213".
* Push the 2.13 branch to dist-git
* `fedpkg clone modules/unison` (this will have been created as part of
request-branch above unless you pass --no-auto-module)
* Switch to the 2.13 branch (also auto-created)
* Create the modulemd file. This can be done easily with 'fedmod'
(currently in updates-testing).
- `fedmod fetch-metadata` (takes a couple minutes the first time)
- `fedmod rpm2module unison213 > unison.yaml` (Filename must match the
dist-git module name plus .yaml, similar to how RPMs have to match the
specfile name)
- Fix the places where the generated file includes "213" (this step is
unique to your situation; others reading this will not need to do this)
- Add `ref: 2.13` under "buildorder" in the YAML so it knows which branch
to pull from.
- If you don't want to build the module on F28, change build and runtime
requires from
platform: [ ]
to
platform: [-f28]
(You could also use `platform: [f29]`, but this wouldn't automatically pick
up F30 when F29 branches).
* Push this branch to dist-git and run `fedpkg module-build`
* Submit the module to Bodhi for F28 if desired. F29/Rawhide will appear
automatically in the modular repos at the next Rawhide compose.

* Repeat for the 2.27 branch


Optional (recommended) step: submit a PR to
https://pagure.io/releng/fedora-module-defaults to have one of the streams
made "default" so that `dnf install unison` will Just Work without having
to know about modules. Other streams can be installed with `dnf install
@unison:2.13
___
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/OVOXWLLCLTFV7OYOQY6NY5EJQUVZWZ5J/

Re: F29 System Wide Change: Hide the grub menu

[Jan Kurik]

Forwarding reply from Ken:

-- Forwarded message --
From: Ken Coar 
To: devel@lists.fedoraproject.org
Cc:
Bcc:
Date: Thu, 31 May 2018 12:20:32 -0400
Subject: Re: F29 System Wide Change: Hide the grub menu
On 05/31/2018 06:43 AM, Jan Kurik wrote:
> = Proposed System Wide Change: Hide the grub menu =
> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
>
> 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'm not [yet] in any of the groups which would allow me to
comment on the wiki, so I'll do it here.

I fundamentally disagree with the 'no useful functionality'
reasoning.  It provides access to the kernel line, even if
there's only one kernel, and that is *definitely* useful
functionality.

I'm opposed to this change.  For one thing, it violates the
Principle of Least Astonishment.  For another, with SSD drives
becoming more and more common, and CPUs faster and faster, the
time window for successfully whanging away at the F8/ESC/F12/whatever
key in order to bring up the menu is getting harder to hit.
Glance away for an instant and you've missed it -- so either let
it come up so you can reboot, or (possibly more common) power it
down (because you can't get in) and try again.

FWIW.
--
#kenB-|}

Ken, Baron Coar
RHCA, RHCVA, Sanagendamgagwedweinini
Red Hat IT Infrastructure

On Thu, May 31, 2018 at 7:14 PM, Chris Adams  wrote:
> Once upon a time, Jason L Tibbitts III  said:
>> If we're going to patch grub to expand the set of keys it will watch
>> for, is it possible to just expand the set to encompass all keys?  We
>> don't really need to make it that hard to find the grub menu, do we?
>
> To add: printing a message to the screen for only a few seconds can be
> almost useless, as many times monitors take those same seconds to sync
> to the output of the GRUB screen (it seems to always be in a different
> mode from the BIOS/UEFI boot screen).  So IMHO, taking any key would be
> good because not only do I not have to remember a specific one or few
> keys, I don't have to read a message that is only actually visible for
> 0.2 seconds.
>
> --
> Chris Adams 
> ___
> 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/ARXFTQA5GMS3XKTCTK46ARROS7C6JUNE/



-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
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/JVBNUB2NC4P4JHWIHATI2547VXG3PWFV/

Re: dnf and deltarpm (Was: Re: Fedora rawhide compose report: 20180529.n.0 changes)

[Neal Gompa]

On Thu, May 31, 2018 at 1:25 PM Tomasz Kłoczko  wrote:
>
> On 29 May 2018 at 15:49, Fedora Rawhide Report  
> wrote:
> [..]
>>
>> Package:  dnf-2.7.5-15.fc29
>> Old package:  dnf-2.7.5-12.fc29
>> Summary:  Package manager
>> RPMs: dnf dnf-automatic dnf-data dnf-yum python2-dnf python3-dnf
>> Added RPMs:   dnf-data
>> Dropped RPMs: dnf-conf
>> Size: 1.82 MiB
>> Size change:  342.44 KiB
>> Changelog:
>>   * Fri May 25 2018 Martin Hatina  - 2.7.5-13
>>   - Rebase to dnf from dnf-2-modularity-6 release.
>>
>>   * Fri May 25 2018 Martin Hatina  - 2.7.5-14
>>   - Fix patch applying.
>>
>>   * Mon May 28 2018 Martin Hatina  - 2.7.5.15
>>   - Do not require libdnf
>
>
> It is yet another hidden change not listed in above.
> python3-dnf subpackage started (again) require deltarp.
> Previouselly is spec was "Recommends: deltarpm" and now it is (again) 
> "Requires: deltarpm"
> dnf maintainer(s) knows about this 
> https://bugzilla.redhat.com/show_bug.cgi?id=1583834
> However for some reason looks like they prefers to apply kind of ostrich 
> tactics.
>
> Because today has been published next dnf release I'm going to repeating the 
> bugzilla ticket question about deltrpm question but this time publically.
>
> I want to believe that it was nothing more than trivial mistake because 
> Fedora does not offer repo with delta files so fixed instead weak dependency 
> does not make here IMO sense, and such change only pointlessly enlarges the 
> size of the @core.
>

The DNF team mistakenly believed that DNF tolerated deltarpm not being
installed like YUM did. That's not the case, so it was reverted. They
originally tried to make it a weak dependency for RHEL, but it didn't
work out well...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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/LMAF533KV5TUTQPO4XU7A2SLBOCEOBEU/

dnf and deltarpm (Was: Re: Fedora rawhide compose report: 20180529.n.0 changes)

[Tomasz Kłoczko]

On 29 May 2018 at 15:49, Fedora Rawhide Report 
wrote:
[..]

> Package:  dnf-2.7.5-15.fc29
> Old package:  dnf-2.7.5-12.fc29
> Summary:  Package manager
> RPMs: dnf dnf-automatic dnf-data dnf-yum python2-dnf python3-dnf
> Added RPMs:   dnf-data
> Dropped RPMs: dnf-conf
> Size: 1.82 MiB
> Size change:  342.44 KiB
> Changelog:
>   * Fri May 25 2018 Martin Hatina  - 2.7.5-13
>   - Rebase to dnf from dnf-2-modularity-6 release.
>
>   * Fri May 25 2018 Martin Hatina  - 2.7.5-14
>   - Fix patch applying.
>
>   * Mon May 28 2018 Martin Hatina  - 2.7.5.15
>   - Do not require libdnf
>

It is yet another hidden change not listed in above.
python3-dnf subpackage started (again) require deltarp.
Previouselly is spec was "Recommends: deltarpm" and now it is (again)
"Requires: deltarpm"
dnf maintainer(s) knows about this
https://bugzilla.redhat.com/show_bug.cgi?id=1583834
However for some reason looks like they prefers to apply kind of ostrich
tactics.

Because today has been published next dnf release I'm going to repeating
the bugzilla ticket question about deltrpm question but this time
publically.

I want to believe that it was nothing more than trivial mistake because
Fedora does not offer repo with delta files so fixed instead weak
dependency does not make here IMO sense, and such change only pointlessly
enlarges the size of the @core.

kloczek
-- 
Tomasz Kłoczko | LinkedIn:http://lnkd.in/FXPWxH
___
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/VV27R66UI323ZXM4OSBAJQTF2SR6ESFI/

[Bug 1584670] perl-Test-Warn-0.34 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Test-Warn-0.34-1.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-05-31 13:16:22



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=27328657

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org/message/Y2BKWJLGDQGGV6QC275QMJM7E7QLZ6VF/

Re: F29 System Wide Change: Hide the grub menu

[Chris Adams]

Once upon a time, Jason L Tibbitts III  said:
> If we're going to patch grub to expand the set of keys it will watch
> for, is it possible to just expand the set to encompass all keys?  We
> don't really need to make it that hard to find the grub menu, do we?

To add: printing a message to the screen for only a few seconds can be
almost useless, as many times monitors take those same seconds to sync
to the output of the GRUB screen (it seems to always be in a different
mode from the BIOS/UEFI boot screen).  So IMHO, taking any key would be
good because not only do I not have to remember a specific one or few
keys, I don't have to read a message that is only actually visible for
0.2 seconds.

-- 
Chris Adams 
___
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/ARXFTQA5GMS3XKTCTK46ARROS7C6JUNE/

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

[Louis Lagendijk]

On Thu, 2018-05-31 at 06:42 -0700, Gerald B. Cox wrote:
> 
> 
> On Thu, May 31, 2018 at 6:08 AM, Chris Adams 
> wrote:
> > Once upon a time, Hans de Goede  said:
> > > And for F30, single OS install we get:
> > > 
> > > 1) grub menu not shown, 0 second timeout, no way to get to the
> > menu
> > > 2) grub menu shown with 5 sec timeout after a failed boot
> > 
> > If I know I want the menu (say I need to boot single-user to fix
> > something), how would I do that in this setup?
> > 
> 
> I'm fine with changing the default - I understand that under normal
> circumstances most people could care less about seeing the screen -
> but I 
> do strongly agree with the comment above.  When things sometimes go
> south and you need that menu, there needs to be a simple, well
> documented
> way to get it... easily... without having to go on a google treasure
> hunt to find the instructions.  Otherwise, don't do it.

How would this feature interact with things like /.autorelabel? Would
the presentation of the grub menu in that case still depend on the
previous boot being marked as successful? Is a boot that only does a
relabel successful?

And how about differences between upgrades (I think that the boot
loader is in that case not re-installed IIRC) vs. new installations.
Could that cause issues?

/Louis
___
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/TIQA4ZSYH2QGMY5NJR6CFXV2RNEJPWKL/

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

[Chris Adams]

Once upon a time, Hans de Goede  said:
> On 31-05-18 15:08, Chris Adams wrote:
> >Once upon a time, Hans de Goede  said:
> >>And for F30, single OS install we get:
> >>
> >>1) grub menu not shown, 0 second timeout, no way to get to the menu
> >>2) grub menu shown with 5 sec timeout after a failed boot
> >
> >If I know I want the menu (say I need to boot single-user to fix
> >something), how would I do that in this setup?
> 
> Hopefully what ever you want to fix will count as a "failed boot"
> if it requires single user mode.

Hmm... not really.  For example (just off the top of my head): lost root
password.  Without it, you won't be able to set any "next boot is
special" option, so resetting root's password would now require rescue
media.

I'd say I'm against this part of your proposal.  I understand the
reasoning, but it just seems like too much restriction to shave off a
small amount of time.  You mentioned it "could take several seconds" for
EFI to initialize USB, but what is the normal time, for a typical
desktop or notebook with just a keyboard and mouse attached?

-- 
Chris Adams 
___
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/RWCCP25CRFMVRDGARYKLRZDV5D6XL7RR/

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

[Matthew Miller]

On Thu, May 31, 2018 at 09:08:28AM -0400, Colin Walters wrote:
> > I'm working on improving the Fedora boot experience, with the
> > end goal being a user pressing the on button and then going
> > to the graphical login manager without him seeing any
> > text messages / menus filled with technical jargon.
> Seems like this is implictly saying "Fedora" to mean (classic) "desktop", but
> we have different editions now.   Further, one of those editions,
> Atomic Host, has fully transactional updates via rpm-ostree that are reflected
> in the bootloader order today - it's not just the kernel.  And we like that 
> feature =)


+1 -- I think we would probably also want the menu by default on
server. (Although, conversely, it's pretty useless in cloud
environments where there isn't an interactive console.)


-- 
Matthew Miller

Fedora Project Leader
___
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/ISEUFONADE6PHGBEFKSC7GFYXORSMU23/

Re: equivalent of Debian config-package?

[Matthew Miller]

On Thu, May 31, 2018 at 03:23:04PM +0100, Dave Love wrote:
> > No such thing currently exists, because an equivalent to `dpkg-divert`
> > does not exist in RPM.
> > It is technically possible to implement such a mechanism, but it does
> > not exist right now.
> Thanks.  I assume even if it was feasible to work on it, it wouldn't
> appear in current RHEL, which would be the main target in this case.

I think generally the Fedora/RH-ecosystem answer is to use Ansible for
configuration, rather than configuration packages.

That's not sayin' there can't be another answer, but in general that's
the route *I'd* take to solve this problem on my systems.

-- 
Matthew Miller

Fedora Project Leader
___
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/LPEJ6UA5V6XJBLEV6O7YG5G5HQGOTJRX/

Re: The update system has the wrong package

[Randy Barlow]

On 05/30/2018 02:23 PM, Steve Dickson wrote:
> You are right... I only did a rawhide build... but that is no longer the case
> https://koji.fedoraproject.org/koji/taskinfo?taskID=27299567
> 
> And I'm still having the problem... the update system is only
> showing rpcsvc-proto-devel instead rpcsvc-proto which is definitely
> since  rpcsvc-proto-devel is part of the rpcsvc-proto package.

As Adam said, you should be able to manually type the NVR into the
candidate builds box.
___
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/KRGOQVU7SIMK3IJ6SPXYT7UT4GUWYFVQ/

Re: The update system has the wrong package

[Randy Barlow]

On 05/29/2018 05:00 PM, Adam Williamson wrote:
>> I'm trying to update the rpcsvc-proto package. 
>> When I try to create a new update, the system
>> only gives me rpcsvc-proto-devel as a choice
>> not rpcsvc-proto.
>>
>> Where do I open up a ticket to get this taken 
>> care of? 

> https://github.com/fedora-infra/bodhi

Bodhi actually queries the packages app for this information, and there
is already an open bug about packages not knowing about new packages:

https://github.com/fedora-infra/fedora-packages/issues/229
___
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/I62VI3OCH32NRWMEA2AU5R66AVDI6IN4/

Re: F29 System Wide Change: Hide the grub menu

[Jason L Tibbitts III]

> "JK" == Jan Kurik  writes:

JK> 1. Add patches to grub to also make pressing F8 show the menu

One thing I've never really understood is the reason for using such a
small set of keys to interrupt the boot process.  I seem to recall that
in older versions (perhaps pre-grub2) the space bar or the cursor keys
worked.  I also recall at some point that you could just hold down the
shift key.  More recently I actually thought something was broken
because I simply couldn't find the magic key (only later finding out
that it had at some point been limited to just 'Esc').

If we're going to patch grub to expand the set of keys it will watch
for, is it possible to just expand the set to encompass all keys?  We
don't really need to make it that hard to find the grub menu, do we?

 - J<
___
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/NHVYIZNFH53EWHV4YUEPHP5JEIUAAZRO/

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

[Hans de Goede]

Hi,

On 31-05-18 15:20, Robert Marcano wrote:

On 05/31/2018 06:52 AM, Hans de Goede wrote:

...
This will basically get us back the F28 behavior of showing the
menu but only after a failed boot, I think that is a good
solution, do you agree?


What is the definition of a successful boot? I ask because a machine could boot 
perfectly, and when you try to interact with it on the login screen, bugs on 
the display driver can change the screen to garbage (I have seen this kind on 
bug long time ago), or lockup. So, the user will be unable to activate any kind 
of restart with menu enabled in order to try an older kernel, or boot to rescue 
mode.

I think instead of only detecting a successful boot, a machine that wasn't 
properly shutdown should enable the menu


A broken install may still shutdown properly after the using pressing the 
power-button and/or
trying ctrl+alt+del.

But this is an interesting suggestion, I think we should track both separately,
so successful shutdown and successful boot and show the menu if either one is
not true. That should make the chance of not being able to get the menu a lot
smaller.

Regards,

Hans
___
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/HS36HXQ5JBXB74ZDX2LTHMJQVWZMBHMB/

Re: Unified Unison package (again)

[Jason L Tibbitts III]

> "RWMJ" == Richard W M Jones  writes:

RWMJ> But wouldn't a single package in fact be preferable, as it'll be
RWMJ> simpler than maintaining multiple packages:

I would argue that it's far from preferable, because you would have
multiple things on different release schedules in one package.  A change
in one version, or adding a new version, forces a pointless update on
all of the subpackages.  (Texlive is an extreme example of how bad this
is.)

That said, texlive is also an example of how this kind of thing has been
reluctantly permitted in the past, but in the case of texlive it's
really only due to that being how the pre-texlive packaging was
historically maintained.  I certainly wouldn't advocate to anything
purposefully switching to that method.

Finally, my understanding is that the packaging guidelines are silent on
the issue.

 - J<
___
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/NTU7AS6P75HPE4L5XC6MKTRPKUOBVBS2/

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

[Hans de Goede]

Hi,

On 31-05-18 16:40, stan wrote:

On Thu, 31 May 2018 12:23:35 +0200
Hans de Goede  wrote:


Hi All,

I'm working on improving the Fedora boot experience, with the
end goal being a user pressing the on button and then going
to the graphical login manager without him seeing any
text messages / menus filled with technical jargon.


I *like* seeing all the stuff flow by, and I boot into multi-user
before starting the graphical user interface.  I like seeing what is
going on under the hood.  Will I still be able to do this?  Or will I
have to hack the install after it is done?


As the "by default" in the Subject implies, this is about setting a
config option, one which is already available today, but the plan
is to change its value, this config option lives in /etc/default/grub
which gets written once during install and then never touched again.

TL;DR: Yes you will still be able to do this with a simple 1 time
configfile change.

Regards,

Hans





Saying this is an improvement is a value judgement.  I agree that many
people might consider this an improvement, but not all.

What is the rationale for doing it?  Imitation of Mac or Windows?
Trying to make it easier for users of Mac or Windows to switch to
Fedora?  What about existing users?  Is it just assumed that they want
this improvement?

It seems clear to me that this change will happen.  I'm just trying to
get you to consider it from different perspectives, to implement it in
such a way that those who don't consider it an improvement have an easy
way to revert to prior behavior.
___
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/UGDIIXTFOR2ALUGOKJ5TI2YXW2ML6HFE/


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

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

[Rob Clark]

On Thu, May 31, 2018 at 11:31 AM, Hans de Goede  wrote:
> Hi,
>
> On 31-05-18 15:08, Chris Adams wrote:
>>
>> Once upon a time, Hans de Goede  said:
>>>
>>> And for F30, single OS install we get:
>>>
>>> 1) grub menu not shown, 0 second timeout, no way to get to the menu
>>> 2) grub menu shown with 5 sec timeout after a failed boot
>>
>>
>> If I know I want the menu (say I need to boot single-user to fix
>> something), how would I do that in this setup?
>
>
> Hopefully what ever you want to fix will count as a "failed boot"
> if it requires single user mode.
>
> I can and certainly will add a commandline utility to force showing
> the menu on the next boot, but that assumes a somewhat working
> system.

I was going to bring up one sort of niche use-case, of installing a
-debug kernel (either while working on the kernel or helping to debug
an issue that the kernel developer cannot reproduce), since debug
kernels end up a lower priority and wouldn't normally be the default
selection.. but a reboot-grubmenu command would totally cover that
use-case.

Side note, android's 'reboot' cmd can take an argument, like 'reboot
fastboot' or 'reboot recovery'.. that might be one of the few features
from android worth copying ;-)

BR,
-R

> I guess the plan is to have a few daemons which are considered
> critical (if enabled) say sshd and gdm and if any of them don't
> start, consider the boot failed. This also means that if you
> ctrl+alt+del early on, causing the system to reboot without
> ever starting those that will also give you the grub menu.
>
> Note that this is exactly why this is a F30 thing, to give us
> a chance to figure out how exactly to detect a failed boot.
>
> Also I would like to note that Windows has been doing more or
> less the same since Vista and it does not seem to cause any
> problems for Windows.
>
> Regards,
>
> Hans
> ___
> 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/P6KOCFBMV4MZF2R4RQKSX4VUO7QD6RWN/
___
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/46GZ2YY54RCD4NZJO25VUNLQYC5REDSF/

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

[Hans de Goede]

Hi,

On 31-05-18 15:08, Colin Walters wrote:



On Thu, May 31, 2018, at 6:23 AM, Hans de Goede wrote:

Hi All,

I'm working on improving the Fedora boot experience, with the
end goal being a user pressing the on button and then going
to the graphical login manager without him seeing any
text messages / menus filled with technical jargon.


Seems like this is implictly saying "Fedora" to mean (classic) "desktop", but
we have different editions now.   Further, one of those editions,
Atomic Host, has fully transactional updates via rpm-ostree that are reflected
in the bootloader order today - it's not just the kernel.  And we like that 
feature =)


I've this on my radar, but I would expect SilverBlue to also not want
to show the menu by default, so although the menu is used a bit differently
the fundamental problems (hide by default, still allow the user access,
pop up automatically on bootfail) apply AFAICT.


There's also a GSoC project to write a boot health check service that
integrates with this: https://pagure.io/fedora-iot/issue/2


Oh, interesting.

Regards,

Hans
___
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/TTQEEXV6O6CJDYBPPA2YAO3ZIDWAVEQB/

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

[Hans de Goede]

Hi,

On 31-05-18 15:08, Chris Adams wrote:

Once upon a time, Hans de Goede  said:

And for F30, single OS install we get:

1) grub menu not shown, 0 second timeout, no way to get to the menu
2) grub menu shown with 5 sec timeout after a failed boot


If I know I want the menu (say I need to boot single-user to fix
something), how would I do that in this setup?


Hopefully what ever you want to fix will count as a "failed boot"
if it requires single user mode.

I can and certainly will add a commandline utility to force showing
the menu on the next boot, but that assumes a somewhat working
system.

I guess the plan is to have a few daemons which are considered
critical (if enabled) say sshd and gdm and if any of them don't
start, consider the boot failed. This also means that if you
ctrl+alt+del early on, causing the system to reboot without
ever starting those that will also give you the grub menu.

Note that this is exactly why this is a F30 thing, to give us
a chance to figure out how exactly to detect a failed boot.

Also I would like to note that Windows has been doing more or
less the same since Vista and it does not seem to cause any
problems for Windows.

Regards,

Hans
___
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/P6KOCFBMV4MZF2R4RQKSX4VUO7QD6RWN/

Re: How to make DNS resolving fail early in mock?

[Miroslav Suchý]

Dne 30.5.2018 v 16:24 Todd Zullinger napsal(a):
> But testing this briefly, the host resolv.conf still ends up
> in the chroot.  I'm probably overlooking something obvious.
> At least, I hope I am.

No, you do not overlook anything. I checked systemd code and they simply 
generate resolv.conf always. And they do when
container start, so mock cannot change it by bind-mount plugin.

For the record. Todd filed this PR:
  https://github.com/rpm-software-management/mock/pull/190
which is on the right track to be merged.

Miroslav



signature.asc
Description: OpenPGP digital signature
___
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/JEBRM5IOPM25WP2NLVRE2XIAJMKJGHMW/

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

[Sam Varshavchik]

Hans de Goede writes:


For F29 the plan is to just hide it (unless a previous boot failed)


What is the exact criteria for "previous boot failed", I'm wondering. Even  
if you reach as far as the GDM screen it's still possible that something is  
so horked up to the point that you can't log in, and you can't shut down  
nicely.


I would also suggest that the criteria must include "something was not  
unmounted cleanly, so if we proceed we will be doing a fsck".


pgpqQgCbw77in.pgp
Description: PGP signature
___
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/AGFSUVTULVW6U6FYR4VH2RSBJOMIR5OA/

Fedora rawhide compose report: 20180531.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180530.n.0
NEW: Fedora-Rawhide-20180531.n.0

= SUMMARY =
Added images:0
Dropped images:  4
Added packages:  17
Dropped packages:4
Upgraded packages:   95
Downgraded packages: 0

Size of added packages:  13.85 MiB
Size of dropped packages:11.96 MiB
Size of upgraded packages:   5.23 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   1.17 GiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Container_Minimal_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Minimal-Base-Rawhide-20180530.n.0.armhfp.tar.xz
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180530.n.0.x86_64.vagrant-libvirt.box
Image: Container_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Base-Rawhide-20180530.n.0.armhfp.tar.xz
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180530.n.0.x86_64.vagrant-virtualbox.box

= ADDED PACKAGES =
Package: airnef-1.1-2.fc29
Summary: Wireless download from your Nikon/Canon Camera
RPMs:airnef
Size:182.22 KiB

Package: gap-pkg-crime-1.4-2.fc29
Summary: Group cohomology and Massey products
RPMs:gap-pkg-crime
Size:573.23 KiB

Package: ghc-cmark-gfm-0.1.3-3.fc29
Summary: Fast, accurate GitHub Flavored Markdown parser and renderer
RPMs:ghc-cmark-gfm ghc-cmark-gfm-devel
Size:4.71 MiB

Package: ghc-hslua-module-text-0.1.2.1-3.fc29
Summary: Lua module for text
RPMs:ghc-hslua-module-text ghc-hslua-module-text-devel
Size:674.91 KiB

Package: golang-github-dropbox-sdk-unofficial-4.1.0-1.fc29
Summary: An UNOFFICIAL Dropbox v2 API SDK for Go
RPMs:golang-github-dropbox-sdk-unofficial-devel
Size:179.30 KiB

Package: mongo-java-driver-3.6.3-1.module_1822+9f9b01c0
Summary: A Java driver for MongoDB
RPMs:mongo-java-driver mongo-java-driver-bson mongo-java-driver-driver 
mongo-java-driver-driver-async mongo-java-driver-driver-core 
mongo-java-driver-javadoc
Size:6.02 MiB

Package: nodejs-acorn-dynamic-import-3.0.0-1.fc29
Summary: Support dynamic imports in acorn
RPMs:nodejs-acorn-dynamic-import
Size:11.75 KiB

Package: nodejs-console-group-0.3.3-1.fc29
Summary: A basic console.group implementation for node
RPMs:nodejs-console-group
Size:9.57 KiB

Package: nodejs-estree-walker-0.5.2-1.fc29
Summary: Traverse an ESTree-compliant AST
RPMs:nodejs-estree-walker
Size:11.97 KiB

Package: nodejs-is-module-1.0.0-1.fc29
Summary: Check if a source string is an es6 module
RPMs:nodejs-is-module
Size:9.34 KiB

Package: nodejs-locate-character-2.0.5-1.fc29
Summary: Get the line and column number of a specific character in a string
RPMs:nodejs-locate-character
Size:10.32 KiB

Package: nodejs-micromatch-3.1.10-1.fc29
Summary: Glob matching for javascript/node.js
RPMs:nodejs-micromatch
Size:26.68 KiB

Package: nodejs-require-relative-0.8.7-1.fc29
Summary: Require and resolve modules relative to a path of your choice
RPMs:nodejs-require-relative
Size:8.33 KiB

Package: nodejs-rollup-pluginutils-2.3.0-1.fc29
Summary: Functionality commonly needed by Rollup plugins
RPMs:nodejs-rollup-pluginutils
Size:14.89 KiB

Package: python-distroinfo-0.0.1-3.fc29
Summary: Parsing and querying distribution metadata stored in text/YAML files
RPMs:python2-distroinfo python3-distroinfo
Size:66.44 KiB

Package: python-netdisco-1.4.0-2.fc29
Summary: Python library to scan local network for services and devices
RPMs:python3-netdisco
Size:72.47 KiB

Package: vkd3d-1.0-1.fc29
Summary: D3D12 to Vulkan translation library
RPMs:libvkd3d libvkd3d-devel libvkd3d-utils libvkd3d-utils-devel
Size:1.31 MiB


= DROPPED PACKAGES =
Package: go-compilers-1-29.module_1635+17c17aa3
Summary: Go language compilers for various architectures
RPMs:go-compilers-golang-compiler
Size:7.85 MiB

Package: go-srpm-macros-2-16.module_1635+17c17aa3
Summary: RPM macros for building Golang packages for various architectures
RPMs:go-srpm-macros
Size:11.24 KiB

Package: 
golang-github-cpuguy83-go-md2man-1.0.7-5.20180307git1d903dc.module_1635+17c17aa3
Summary: Process markdown into manpages
RPMs:golang-github-cpuguy83-go-md2man golang-github-cpuguy83-go-md2man-devel
Size:3.72 MiB

Package: 
golang-github-russross-blackfriday-2.0.0-1.20180215git55d61fa.module_1635+17c17aa3
Summary: Markdown processor implemented in Go
RPMs:golang-github-russross-blackfriday-devel 
golang-github-russross-blackfriday-unit-test
Size:376.27 KiB


= UPGRADED PACKAGES =
Package:  R-IRdisplay-0.5.0-1.fc29
Old package:  R-IRdisplay-0.4.4-3.fc29
Summary:  'Jupyter' Display Machinery
RPMs: R-IRdisplay
Size: 39.18 KiB
Size change:  6.75 KiB
Changelog:
  * Wed May 30 2018 Elliott Sales de Andrade  - 
0.5.0-1
  - Update

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

[stan]

On Thu, 31 May 2018 12:23:35 +0200
Hans de Goede  wrote:

> Hi All,
> 
> I'm working on improving the Fedora boot experience, with the
> end goal being a user pressing the on button and then going
> to the graphical login manager without him seeing any
> text messages / menus filled with technical jargon.

I *like* seeing all the stuff flow by, and I boot into multi-user
before starting the graphical user interface.  I like seeing what is
going on under the hood.  Will I still be able to do this?  Or will I
have to hack the install after it is done?

Saying this is an improvement is a value judgement.  I agree that many
people might consider this an improvement, but not all.

What is the rationale for doing it?  Imitation of Mac or Windows?
Trying to make it easier for users of Mac or Windows to switch to
Fedora?  What about existing users?  Is it just assumed that they want
this improvement?

It seems clear to me that this change will happen.  I'm just trying to
get you to consider it from different perspectives, to implement it in
such a way that those who don't consider it an improvement have an easy
way to revert to prior behavior.
___
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/UGDIIXTFOR2ALUGOKJ5TI2YXW2ML6HFE/

Re: equivalent of Debian config-package?

[Neal Gompa]

On Thu, May 31, 2018 at 10:23 AM Dave Love  wrote:
>
> Neal Gompa  writes:
>
> > No such thing currently exists, because an equivalent to `dpkg-divert`
> > does not exist in RPM.
> >
> > It is technically possible to implement such a mechanism, but it does
> > not exist right now.
>
> Thanks.  I assume even if it was feasible to work on it, it wouldn't
> appear in current RHEL, which would be the main target in this case.

Sure, but maybe next RHEL? ;)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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/O4WGI2BZ6TOFJ36XJEZFE6MWJPSH7Y7U/

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

[Michael Cronenworth]

On 05/31/2018 08:42 AM, Gerald B. Cox wrote:
I'm fine with changing the default - I understand that under normal circumstances 
most people could care less about seeing the screen - but I
do strongly agree with the comment above.  When things sometimes go south and you 
need that menu, there needs to be a simple, well documented
way to get it... easily... without having to go on a google treasure hunt to find 
the instructions. Otherwise, don't do it.


Replace the grub menu with "Press any key to access GRUB" or something similar at 
the bottom of the screen to at least be a visual clue.

___
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/4PJ53XJN5LY2FWN7OGNJDYITVFPDVXIU/

Re: equivalent of Debian config-package?

[Dave Love]

Neal Gompa  writes:

> No such thing currently exists, because an equivalent to `dpkg-divert`
> does not exist in RPM.
>
> It is technically possible to implement such a mechanism, but it does
> not exist right now.

Thanks.  I assume even if it was feasible to work on it, it wouldn't
appear in current RHEL, which would be the main target in this case.
___
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/7BOZOLUXMQD7QNK53QC5WXDUEPIIRD4T/

Re: Unified Unison package (again)

[Richard W.M. Jones]

On Thu, May 31, 2018 at 08:53:25AM -0400, Stephen Gallagher wrote:
> Are these packages parallel-installable (and do they need to be?)

In theory, although practically it probably wouldn't be the end of the
world if they were not parallel installable (it's my understanding
that the current module proposal does not allow parallel installation
of modules).

The scenario were parallel installation would be useful is something
like you want to synch between *three* machines with mutually
incompatible versions of unison, and the Fedora machine in the middle
needing both.  It's pretty obscure.

> It seems
> to me like this would be a FAR better solution as a module. You just have
> branches for the major/minor releases and then ship module streams for each
> one. They can be built and updated independently (rather than rebuilding
> all of them each time any of them releases an update).
> 
> I can help you with this, if it's an approach you want to take.

It's worth looking at certainly.  Could you look at these two files
and tell me how they could be turned into a module?  If you look at
them side by side you can see they are very similar, probably one
derived from the other at some point in the past:

https://src.fedoraproject.org/rpms/unison213/blob/master/f/unison213.spec
https://src.fedoraproject.org/rpms/unison227/blob/master/f/unison227.spec

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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/message/A3YJLR55B2OG2OI63A6XOECDBSM5U6AB/

[Bug 1584611] perl-Net-LibIDN2-1.00-3.fc29 FTBFS: Failed test at t/ 001_basic.t

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Net-LibIDN2-1.00-2.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-021e17f0e9

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org/message/JUVGBWG6G6TNMJFU2AAIBQGTOTKK3MZ5/

[Bug 1584611] perl-Net-LibIDN2-1.00-3.fc29 FTBFS: Failed test at t/ 001_basic.t

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Net-LibIDN2-1.00-4.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-bcfc2a7cce

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org/message/EEX3AQ6KKEZ23LF3OKKAUHRBD4WDCOZF/

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

[Gerald B. Cox]

On Thu, May 31, 2018 at 6:08 AM, Chris Adams  wrote:

> Once upon a time, Hans de Goede  said:
> > And for F30, single OS install we get:
> >
> > 1) grub menu not shown, 0 second timeout, no way to get to the menu
> > 2) grub menu shown with 5 sec timeout after a failed boot
>
> If I know I want the menu (say I need to boot single-user to fix
> something), how would I do that in this setup?
>
>
I'm fine with changing the default - I understand that under normal
circumstances most people could care less about seeing the screen - but I
do strongly agree with the comment above.  When things sometimes go south
and you need that menu, there needs to be a simple, well documented
way to get it... easily... without having to go on a google treasure hunt
to find the instructions.  Otherwise, don't do it.
___
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/FRCZQXHKVW3B4NXHIYWYI6D7FX7BF4XG/

Re: Unified Unison package (again)

[Stephen John Smoogen]

On 31 May 2018 at 09:13, Stephen Gallagher  wrote:
>
>
> On Thu, May 31, 2018 at 9:07 AM Till Maas  wrote:
>>
>> On Thu, May 31, 2018 at 08:53:25AM -0400, Stephen Gallagher wrote:
>>
>> > Are these packages parallel-installable (and do they need to be?) It
>> > seems
>>
>> Yes and yes, otherwise one could not synchronise between older and newer
>> Fedoras.
>>
>
> If they needed to sync between older systems, couldn't the newer ones just
> all standardize on the oldest, most-compatible one?
>
>>
>> > to me like this would be a FAR better solution as a module. You just
>> > have
>> > branches for the major/minor releases and then ship module streams for
>> > each
>> > one. They can be built and updated independently (rather than rebuilding
>> > all of them each time any of them releases an update).
>>
>> Why is a module here better than parallel installable RPMs?
>>
>
> Package maintenance would be simpler, there would be less updates churn
> compared to having all of the streams in a single SRPM, the UI for
> installing the right version would be easier on the end-user...
>
> I'd really like to hear how often in the real world that users actually
> install more than one version of unison on the same system. It doesn't seem
> like the sort of thing people would do very often, since maintenance would
> be difficult.
>

The university people I have dealt with have multiple versions
installed because the upstreams they need stuff from are all using
different versions. I don't think modules makes a good case here
because these things have 'infinite' lifetimes so will be kept up for
'ever' and the users are usually needing multiple versions.




-- 
Stephen J Smoogen.
___
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/A65FZTAS6UIBRTRQNP3DAJE7M6XMUF7S/

[Bug 1584611] perl-Net-LibIDN2-1.00-3.fc29 FTBFS: Failed test at t/ 001_basic.t

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Net-LibIDN2-1.00-4.fc2
   ||9



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org/message/JHVSVNB2WPUZBB5VZ3BUWBTQEBIEVFMY/

Re: Unified Unison package (again)

[Richard W.M. Jones]

On Thu, May 31, 2018 at 01:45:19PM +0100, Tom Hughes wrote:
> On 31/05/18 13:31, Richard W.M. Jones wrote:
> 
> >Although this is very slightly dubious from a packaging point of view,
> >I believe it's the best solution here.  It means we can build multiple
> >versions, we don't need to go through the new package review process
> >every time upstream releases a new major version, and it'll make
> >managing the package simpler at the cost of a somewhat more complex
> >spec file.
> 
> So long as the different versions don't conflict you don't actually
> need a new review to package a different version - there is now an
> automatic exception for that:
> 
> https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Process
> 
> and:
> 
> https://pagure.io/packaging-committee/issue/637

But wouldn't a single package in fact be preferable, as
it'll be simpler than maintaining multiple packages:

 - Everything visible in one spec file.

 - Only a single search to show all bugs.

 - Single method to find all supported unison versions.

 - Mass rebuild once.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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/537ZLQDEPYIJSAU3S3ER54U42ISTDEPN/

[Test-Announce] Fedora 29 Rawhide 20180531.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 29 Rawhide 20180531.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
pungi - 20180524.n.0: pungi-4.1.25-1.fc29.src, 20180531.n.0: 
pungi-4.1.25-2.fc29.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/29

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180531.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180531.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180531.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180531.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180531.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180531.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180531.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org/message/ZXURN47UPYUKXQUX4MC4H7BWKBQHLZL7/
___
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/ZXURN47UPYUKXQUX4MC4H7BWKBQHLZL7/

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

[Robert Marcano]

On 05/31/2018 06:52 AM, Hans de Goede wrote:

...
This will basically get us back the F28 behavior of showing the
menu but only after a failed boot, I think that is a good
solution, do you agree?


What is the definition of a successful boot? I ask because a machine 
could boot perfectly, and when you try to interact with it on the login 
screen, bugs on the display driver can change the screen to garbage (I 
have seen this kind on bug long time ago), or lockup. So, the user will 
be unable to activate any kind of restart with menu enabled in order to 
try an older kernel, or boot to rescue mode.


I think instead of only detecting a successful boot, a machine that 
wasn't properly shutdown should enable the menu





Regards,

Hans

___
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/5HGEILCQDSDBPGBBZVTRMTG26XNGSE6P/

Re: Unified Unison package (again)

[Stephen Gallagher]

On Thu, May 31, 2018 at 9:07 AM Till Maas  wrote:

> On Thu, May 31, 2018 at 08:53:25AM -0400, Stephen Gallagher wrote:
>
> > Are these packages parallel-installable (and do they need to be?) It
> seems
>
> Yes and yes, otherwise one could not synchronise between older and newer
> Fedoras.
>
>
If they needed to sync between older systems, couldn't the newer ones just
all standardize on the oldest, most-compatible one?


> > to me like this would be a FAR better solution as a module. You just have
> > branches for the major/minor releases and then ship module streams for
> each
> > one. They can be built and updated independently (rather than rebuilding
> > all of them each time any of them releases an update).
>
> Why is a module here better than parallel installable RPMs?
>
>
Package maintenance would be simpler, there would be less updates churn
compared to having all of the streams in a single SRPM, the UI for
installing the right version would be easier on the end-user...

I'd really like to hear how often in the real world that users actually
install more than one version of unison on the same system. It doesn't seem
like the sort of thing people would do very often, since maintenance would
be difficult.
___
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/G7VJ7RWMIPHXMXNBW5CPWGVYBY5XGOHB/

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

[Colin Walters]

On Thu, May 31, 2018, at 6:23 AM, Hans de Goede wrote:
> Hi All,
> 
> I'm working on improving the Fedora boot experience, with the
> end goal being a user pressing the on button and then going
> to the graphical login manager without him seeing any
> text messages / menus filled with technical jargon.

Seems like this is implictly saying "Fedora" to mean (classic) "desktop", but
we have different editions now.   Further, one of those editions,
Atomic Host, has fully transactional updates via rpm-ostree that are reflected
in the bootloader order today - it's not just the kernel.  And we like that 
feature =)

There's also a GSoC project to write a boot health check service that
integrates with this: https://pagure.io/fedora-iot/issue/2
___
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/MZDCUZJCOIPAKSXIC6GCIDBBBXXQATFT/

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

[Chris Adams]

Once upon a time, Hans de Goede  said:
> And for F30, single OS install we get:
> 
> 1) grub menu not shown, 0 second timeout, no way to get to the menu
> 2) grub menu shown with 5 sec timeout after a failed boot

If I know I want the menu (say I need to boot single-user to fix
something), how would I do that in this setup?

-- 
Chris Adams 
___
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/5UEVATV7WC2RTCWIT4MPIBVHPQN5IUN5/

Re: Unified Unison package (again)

[Till Maas]

On Thu, May 31, 2018 at 08:53:25AM -0400, Stephen Gallagher wrote:

> Are these packages parallel-installable (and do they need to be?) It seems

Yes and yes, otherwise one could not synchronise between older and newer
Fedoras.

> to me like this would be a FAR better solution as a module. You just have
> branches for the major/minor releases and then ship module streams for each
> one. They can be built and updated independently (rather than rebuilding
> all of them each time any of them releases an update).

Why is a module here better than parallel installable RPMs?

Kind regards
Till
___
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/YJ5TDDECMHYSWTSPW3K6WHIU5VABFANV/

Re: F29 System Wide Change: Hide the grub menu

[Kamil Paral]

On Thu, May 31, 2018 at 12:52 PM, Sam Varshavchik 
wrote:

> Jan Kurik writes:
>
> = 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.
>>
>
> Ummm, yes it does. It lets you boot into single user mode, or select the
> previous kernel to boot. That might be a critical function, in an emergency.
>

The next few lines of the proposal covers exactly the point you're making.
___
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/KCN4MZHGXEAADUYU7WXOMYHPNP2C5J7A/

Re: Unified Unison package (again)

[Stephen Gallagher]

On Thu, May 31, 2018 at 8:32 AM Richard W.M. Jones 
wrote:

> Previously discussed several times, most recently:
>
> * 2015
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KQ523Z3S3VUATKU6V2NASAPGBKR5EJWC/
> * 2011
> https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.html#157495
>
> Unison is a fairly widely used file synchronization package. Think of
> it as a more efficient, multi-directional 'rsync'.
>
> Unison has the unfortunate property that versions of Unison are not
> compatible with each other unless they have the exact same major.minor
> release. eg. Unison 2.40.128 is compatible with Unison 2.40.102, but
> incompatible with Unison 2.48.3 (the latest upstream).
>
> The reason that matters is you might be running Unison across multiple
> machines, running different Linux distros, which have different
> versions of Unison.
>
> For this reason, Fedora packages three different Unison branches in
> separate packages:
>
> * unison213 (currently Unison 2.13.16)
> * unison227 (currently Unison 2.27.157)
> * unison240 (currently Unison 2.40.128)
> * There was a "unison" package, but it is retired
>
> We don't package the latest upstream versions (Unison 2.48.4,
> Unison 2.51.2) at all.
>
> Because of what I said above, it matters what Debian is shipping:
>
> * unison 2.27.57
> * unison 2.32.52
> * unison 2.40
>
> => If you wanted to communicate between Fedora and Debian you could
> use either 2.27 or 2.40.
>
> It's not likely that Unison will use a stable, cross-version protocol
> any time soon.
>
> I'm proposing that we clear up this mess by creating a single unified
> package called just "unison" which will build subpackages for each
> version.  It will contain multiple source tarballs for each major
> branch.
>
> Although this is very slightly dubious from a packaging point of view,
> I believe it's the best solution here.  It means we can build multiple
> versions, we don't need to go through the new package review process
> every time upstream releases a new major version, and it'll make
> managing the package simpler at the cost of a somewhat more complex
> spec file.
>
> If no one has any objections, I'll submit a unified unison package to
> the new package process.
>
>
Are these packages parallel-installable (and do they need to be?) It seems
to me like this would be a FAR better solution as a module. You just have
branches for the major/minor releases and then ship module streams for each
one. They can be built and updated independently (rather than rebuilding
all of them each time any of them releases an update).

I can help you with this, if it's an approach you want to take.
___
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/LUJRS5TUM7UQSMN2HEZPSDGLMAEJXYLE/

[Bug 1584662] perl-FFI-CheckLib-0.19 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-FFI-CheckLib-0.19-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-7c65572604

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org/message/WD7OYZDRWS62E22NOSTV7MXREVFPLVAZ/

Re: Unified Unison package (again)

[Tom Hughes]

On 31/05/18 13:31, Richard W.M. Jones wrote:


Although this is very slightly dubious from a packaging point of view,
I believe it's the best solution here.  It means we can build multiple
versions, we don't need to go through the new package review process
every time upstream releases a new major version, and it'll make
managing the package simpler at the cost of a somewhat more complex
spec file.


So long as the different versions don't conflict you don't actually
need a new review to package a different version - there is now an
automatic exception for that:

https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Process

and:

https://pagure.io/packaging-committee/issue/637

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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/H3ZWZMIZUNRHHHEKYRXFBGPWSUY7PECL/

[Bug 1584662] perl-FFI-CheckLib-0.19 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-FFI-CheckLib-0.19-1.fc
   ||29



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 28.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org/message/SMZGIYMXMHA4EPNXFXK66ETMBA7RQUGY/

Unified Unison package (again)

[Richard W.M. Jones]

Previously discussed several times, most recently:

* 2015 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KQ523Z3S3VUATKU6V2NASAPGBKR5EJWC/
* 2011 
https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.html#157495

Unison is a fairly widely used file synchronization package. Think of
it as a more efficient, multi-directional 'rsync'.

Unison has the unfortunate property that versions of Unison are not
compatible with each other unless they have the exact same major.minor
release. eg. Unison 2.40.128 is compatible with Unison 2.40.102, but
incompatible with Unison 2.48.3 (the latest upstream).

The reason that matters is you might be running Unison across multiple
machines, running different Linux distros, which have different
versions of Unison.

For this reason, Fedora packages three different Unison branches in
separate packages:

* unison213 (currently Unison 2.13.16)
* unison227 (currently Unison 2.27.157)
* unison240 (currently Unison 2.40.128)
* There was a "unison" package, but it is retired

We don't package the latest upstream versions (Unison 2.48.4,
Unison 2.51.2) at all.

Because of what I said above, it matters what Debian is shipping:

* unison 2.27.57
* unison 2.32.52
* unison 2.40

=> If you wanted to communicate between Fedora and Debian you could
use either 2.27 or 2.40.

It's not likely that Unison will use a stable, cross-version protocol
any time soon.

I'm proposing that we clear up this mess by creating a single unified
package called just "unison" which will build subpackages for each
version.  It will contain multiple source tarballs for each major
branch.

Although this is very slightly dubious from a packaging point of view,
I believe it's the best solution here.  It means we can build multiple
versions, we don't need to go through the new package review process
every time upstream releases a new major version, and it'll make
managing the package simpler at the cost of a somewhat more complex
spec file.

If no one has any objections, I'll submit a unified unison package to
the new package process.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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/RBOQEJY4QHNPDUTUU7GCNVJLNEH6JYKN/

[Bug 1584670] New: perl-Test-Warn-0.34 is available

[bugzilla]

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

Bug ID: 1584670
   Summary: perl-Test-Warn-0.34 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-Warn
  Keywords: FutureFeature, Triaged
  Assignee: tcall...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
tcall...@redhat.com



Latest upstream release: 0.34
Current version/release in rawhide: 0.33-1.fc29
URL: http://search.cpan.org/dist/Test-Warn/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3425/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org/message/4HJ5UD4JMVF4IU3IRF67JTLEWBQFFSL5/

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

[Hans de Goede]

Hi,

On 31-05-18 13:59, Stephen Gallagher wrote:



On Thu, May 31, 2018 at 6:53 AM Hans de Goede mailto:hdego...@redhat.com>> wrote:

Hi,

On 31-05-18 12:36, Stephen Gallagher wrote:
 >
 > On Thu, May 31, 2018 at 6:24 AM Hans de Goede mailto:hdego...@redhat.com> >> wrote:
 >
 >     Hi All,
 >
 >     I'm working on improving the Fedora boot experience, with the
 >     end goal being a user pressing the on button and then going
 >     to the graphical login manager without him seeing any
 >     text messages / menus filled with technical jargon.
 >
 >     IIRC we used to hide the grub-menu by default on single
 >     OS installs, but we seemed to have stopped doing that,
 >     for new Fedora 29 installs I would like us to start
 >     hiding the menu by default on single OS installs again,
 >     see:
 >
 > https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
 >
 >     The goal if this email is to:
 >     1) Give people an advance warning about the plan to change
 >     this so we can discuss this early on
 >
 >     2) See if anyone knows why we stopped doing this, I think
 >     we may simply have stopped doing this to simplify to bootconfig
 >     code in anaconda and because we did not always identify the
 >     single OS case correctly, but I wonder if there were other
 >     reasons?
 >
 >
 >
 > I think part of the reason is that non-technical people might not know 
how to recover if a kernel update had a regression leaving their system 
unbootable. At least with the boot config screen there, it offers them something 
to try.
 >
 > I would be concerned if we drop this without instituting an alternative 
way to (perhaps automatically) revert to an older kernel if boot failed to reach 
some sensible systemd target.

Revert to the older kernel, or show the menu?


Showing the menu provides the user a way to revert to the older kernel, so it's 
fine with me.


Ok.


I also have working on fastboot support on my TODO, which means not
checking for a keypress in grub *at all* because that check will
cause EFI firmware to scan all USB busses for a keyboard which can
be quite slow. This indeed involves setting a "boot_success"
grub environment variable, which grubs clears at boot and if
not re-set the next boot grub will not fastboot.


Interesting. How slow are we talking about? Measured in milliseconds or seconds?


Up to multiple seconds (depending on the hardware and amount of attached
USB devices).


The fastboot stuff is more of a Fedora 30 then 29 thing, but I
guess I could bring the bits which signal a successful boot
forwards to 29 and use that to decide between showing the menu
with our default 5 second timeout and hiding it and waiting 1 sec.


If we are hiding it and have no detected keyboard, what's the value of waiting 
one second anyway? Shouldn't we skip the wait entirely?


For F29 the plan is to just hide it (unless a previous boot failed)
the not checking for a keypress is the full fastboot implementation
which is best left for Fedora 30 I think. Once we get the full
fastboot implementation then the 1 second delay indeed will be
removed.

So for F29, single OS install we get:

1) grub menu hidden by default with a 1 second timeout to press ESC
or F8 to show it
2) grub menu shown with 5 sec timeout after a failed boot

And for F30, single OS install we get:

1) grub menu not shown, 0 second timeout, no way to get to the menu
2) grub menu shown with 5 sec timeout after a failed boot

Originally I was planning on doing the failed-boot detect only
for F30, but I agree it makes sense to have it for F29 and this
will also give us some field testing of this while we still have
a fallback in the form of the 1 sec wait for ESC / F8.

This is all defaults btw and can all be overridden by the user if
so desired.

Regards,

Hans
___
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/BYAFAPUNZRN4JUNFIIOX4E7XELMJJ7QD/

[Bug 1584662] New: perl-FFI-CheckLib-0.19 is available

[bugzilla]

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

Bug ID: 1584662
   Summary: perl-FFI-CheckLib-0.19 is available
   Product: Fedora
   Version: rawhide
 Component: perl-FFI-CheckLib
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.19
Current version/release in rawhide: 0.18-2.fc28
URL: http://search.cpan.org/dist/FFI-CheckLib/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/13614/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org/message/5IB7LKE6X3VUNMEG5ROUHHKOERHLKVSR/