date:20191206

On Fri, Dec 6, 2019 at 7:26 PM Adam Williamson 
wrote:

> On Fri, 2019-12-06 at 18:51 -0600, Richard Shaw wrote:
> > After reading this thread I think this is a more serious problem than
> just
> > this package. I had "assumed" modules were just normal, so I didn't
> > question them being installed.
>
> They are normal. You're not wrong. The problem is well understood at
> this point: a module was given a stream default - meaning it becomes
> the default source of packages it contains. That module includes
> protobuf, meaning it takes over from the non-modular repo as the
> default source of protobuf. The build of protobuf it contains was
> missing some bits that other packages depend on, which broke those
> packages.
>

I guess I should say that part of my problem is that:

1. I didn't ask for/want a module.
2. They aren't actually needed. After disabling them and reinstalling the
programs I care about (or could have used distro-sync) they weren't
actually needed.


> I have not intentionally enabled/installed any modules but through regular
> > updates I now have the following installed:
>
> Well, yes. That's what happens. If this didn't actually break anything
> for you, you don't really need to panic, but if you want to sync with
> the current state (where the module stream default has been removed at
> least temporarily), just disable the modules that were enabled and then
> run 'dnf distro-sync'. That should return you to the non-modular
> builds.
>

I guess I understand some programs needed a specific/older version of
something as a "good" reason to put something in a module, but I'm finding
myself more a purest and I don't think we should have more than one source
of "truth", or in this case, multiple ways to fulfill a dependency.

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

[389-devel] 389 DS nightly 2019-12-07 - 95% PASS

2019-12-06 Thread vashirov

https://fedorapeople.org/groups/389ds/ci/nightly/2019/12/07/report-389-ds-base-1.4.2.5-20191207gitd527003.fc31.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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1779900] perl-Archive-Extract-0.84 is available

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



--- Comment #5 from Fedora Update System  ---
perl-Archive-Extract-0.84-1.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-71bee7d558

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1744690] [RFE] EPEL8 branch of perl-Plack

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #14 from Fedora Update System  ---
perl-Plack-1.0047-7.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5d2caf321b

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1761850] perl-Crypt-Rijndael for EL8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-Crypt-Rijndael-1.14-2.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f7dedf8596

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

On Friday, December 6, 2019 5:14:24 PM MST Kevin Kofler wrote:
> Marius Schwarz wrote:
> 
> > "Figure out intersection with current work to use the TPM to allow
> > booting to GDM without entering the password."
> > 
> > Means, if someone steals the device, he can boot a system.
> 
> 
> And conversely, if you move the hard disk to another computer, you can no 
> longer read it. And if your motherboard breaks down, instant data loss.
> 
> In addition, I do not trust the TPM or any other Treacherous Computing 
> component.
> 
> If you want to rely on a hardware key, it should at least be on a removable
>  USB token (a keyfile on a plain mass-storage USB stick is enough!), not
> hard-wired into the computer like the TPM.

Agreed. What many people don't realize is that a TPM isn't some special 
security device. It's essentially a specialized storage device, that only 
stores keys, with a few extensions to use those keys. On many vendors, the TPM 
includes a key that CANNOT BE REMOVED, which belongs to Microsoft or an OEM.


-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

On Friday, December 6, 2019 3:22:48 PM MST Chris Murphy wrote:
> Is it your position that encrypting ~/ alone is not an incremental
> improvement? Are you suggesting it's necessary to assume Fedora
> Workstation users are subject to targeted attacks? And therefore
> install time default must encrypt /, /home, swap? And that this
> targeted attack, that applies to everyone, does not include targeted
> attacks on unencrypted /boot or the bootloader for reasons you refuse
> to elaborate on? And you propose that users should have to opt out of
> this, rather than opt in?

There's a lot to unpack here, so let me break this down.

Encrypting $HOME would certainly be "an incremental improvement", but it 
shouldn't be done unless the user chooses to do it, and it probably shouldn't 
be done using the same passphrase they use for their user account. That should 
be up to the user to decide, of course. If they want to use the same 
passphrase, far be it from me to attempt to stop them.

A much better solution would be to push users towards giving full disk 
encryption a try. I'd recommend doing this by a prompt during partitioning 
that has no default option, but is simply a "Yes" or "No" as to whether or not 
they want it encrypted, when using default automatic partitioning.

/boot should also be encrypted. I have never said otherwise.

I believe I've already answered the question as to "opt out of this, rather 
than opt in", but I'll make that a bit more verbose. I don't believe that 
either should be forced upon the user. It's an important decision, and one 
which should be made by the user, not by somebody else that thinks they know 
best. There are some that argue that more options make the installation 
"harder" or a "worse experience". I'd argue that those people are understating 
the value of these important options.

> It's already implemented. There is no encryption by default.

That's not what I was referring to. That was in reference to the use of keys 
stored on a TPM to automatically decrypt the system at boot time.

> You've set up a false dilemma where the only two valid options are do
> nothing and do what you want.

I've not said anything which would indicate that to be the case, nor do I 
believe I have all of the answers. I've never stated that there are only two 
valid options. I've only stated that some things which have been suggested are 
not valid options, and I've attempted to provide ideas for potential 
solutions. That's the end goal, collaborative suggestions leading to the best 
potential solution.

> You reject all intermediate options, dismissing them out of turn without any
> meaningful evaluation.

Do you have an example of this? I don't believe that's the case. If you're 
referring to systemd-homed, there are a myriad of issues with it, which I and 
others have brought up in this thread and elsewhere.

> And that's on top of having said you are unconcerned with GNOME and don't
> care about the outcome. If you don't care, why are you still arguing?

GNOME is not the only desktop environment in Fedora.

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

On Friday, December 6, 2019 11:22:34 AM MST Chris Murphy wrote:
> On Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr 
> wrote:
> >
> >
> > On Thursday, December 5, 2019 8:12:13 PM MST Chris Murphy wrote:
> > 
> > > Using the word to be defined in the definition is insufficient and
> > > vague. It's meaningless.
> > >
> > >
> > >
> > > Feature existence is not support. The community members make a thing
> > > supported, and it's only by community effort and prioritization that
> > > features are supported. The track record of hibernation support, such
> > > as it is, is best effort, but not blocking. If it breaks, Fedora ships
> > > with it broken. There are flat out not enough resources to treat it
> > > with any higher priority than this - it's not a new issue either.
> >
> >
> >
> > Nonetheless, it is "supported" in Fedora.
> 
> 
> And now you're using private terminology, and it amounts to denialism
> and arguing rather than issue progression. It's tedious and makes the
> conversation as pointless as talking to a wall.

If anything, you're the one with a weird definition of the term. It's 
supported in Fedora. It's there. Out of box. It seems it's not supported on a 
specific configuration, from what you've provided, but it's supported on the 
vast majority of systems, where that specific configuration is not in use.

> And likewise there are minimum expectations of reliability for
> something to be enabled by default, and hibernation does not qualify.
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> thread/Q5KQC2SZW42I7ABJGXOZNHQLIBLU5DFO/

And yet, it's enabled by default.

> In the first paragraph you correctly state Secure Boot limits what
> boots to code that's been signed by Fedora's signing key (or
> alternatively user keys, if so configured).

No, I describe it as relying on vendor keys. This is a fundamental flaw in 
Secure Boot.

> And in the second you describe a means of thwarting Secure Boot by
> permitting arbitrary code execution, and advocate for this by default, while
> also questioning the decision making capacity of others.

Bypassing a flawed system, which was originally designed to limit the 
operating systems that could be installed on hardware. Please do not forget 
the history of "Secure Boot", or it's original intentions.

> What does encryption have to do with it? Do you think encryption
> mimics or is akin to code signing? Does it provide error detection or
> error correction? If you change a single block of encrypted data do
> you think upon decryption there's EIO or some kind of warning?

If the swap partition is encrypted, it's not possible to modify it in a manner 
that would compromise security, only in a manner which would make the data 
invalid, and only if using `discard` for that luks container.

> You're making excuses for an unprivileged process fork bombing a
> default installation. And you're also changing the goal post by
> blaming the user.

If the user chooses to run something, that's up to them. I've given you the 
solution.

> The topic, set by you, is the assertion that you've never seen a
> system freeze up when swap size is at least 1x RAM. I have provided a
> reproducer that contradicts this. And instead of acknowledging that,
> either at face value or testing it yourself, you proceed with totally
> off topic distractions that also blame the user.

That's simply not the case. I explained that what you provided is easily 
mitigated, with proper configuration. It is a non-issue.

> It's a debate style that is intended to generate more debate without
> conclusion or progression of the issues, and I consider it
> intellectually dishonest.

Again, a solution to the problem was provided. If you have an issue with it, 
we can discuss that off-list, or in a new thread specific to that issue. A 
more relevant mailing list for that would be fedora-users, where users 
commonly ask for assistance with configuration.

> > That's because it is supported. It works out of box, and several DEs even
> > have a button for it. I don't know if GNOME does, but the GNOME Spin has
> > always been a bit special.
> 
> 
> More private terminology, as if you think repeating it will make it
> stick. The difference with my repetition is it's backed by dozens of
> conversations among various developers and stakeholders in the Fedora
> community considering it not supported, it isn't me personally
> asserting a belief or fantasy.

What are you suggesting is "private terminology", other than "GNOME Spin"? You 
know that I'm referring to what others call "Workstation", which is a misnomer 
in my opinion.

It's simply false to say that hibernation is not supported. Not only is it 
supported, there's a big button for it in the major DEs. I have not tested 
GNOME, but I'd be willing to be it's there, unless something has changed with 
the shutdown menu since the version of GNOME 3 used in RHEL 7. Please do let 
me know if GNOME is missing that button in Fedora,

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

On Friday, December 6, 2019 10:05:42 AM MST Przemek Klosowski via devel wrote:
> Many systems have 8, 16 or even 32GB of RAM now. Mine has 16GB, and and
> I regularly run out of memory because some Chrome tab is open to a
> website that keeps reloading ads and leaking memory, sometimes consuming
> gigabytes per tab.

I could only suggest not to use proprietary software, such as Chrome.

> The disk speed being in the double digit MB/s, swapping multiple GB
> takes minutes. During this time, the system is unresponsive,
> unfortunately---the mouse is frozen, alt-tab does not switch between
> apps, etc. Sometimes I can flip to a text console and kill chrome, but
> most of the time the only remedy is to wait it out or force reboot. I am
> not sure if the freezing is mostly kernel's fault or the display
> subsystem's fault.
> 
> For that reason, I don't believe that the old advice of swap = 2*RAM  is
> relevant today. Even 1*RAM is of questionable utility---the main reason
> for 1*RAM guideline is the ability to hibernate to swap, in my opinion.
> Instead, I'd say that with the RAM prices being what they are, everyone
> should try to buy as much RAM as appropriate for their regular use.

That's not really an option for many users, such as myself. For example, the 
maximum amount of memory one could install in the system that I'm using to 
type this message on is 8 GiB. That is, a maximum of two slots of 4 GiB.

I'd rather just not use software that constantly leaks memory, and so I don't 
use web browsers often, but I use either Falkon or Firefox when I do need a 
web browser. This probably wouldn't work for most people, as it's common for 
folks to prefer to do everything in web browsers these days, and I get that. 
To each their own. I still build my systems with 1*RAM, and set the swappiness 
as appropriate. It seems to work out well for me, and so I can only recommend 
that others give it a try, to see if it works for them.

-- 
John M. Harris, Jr.
Splentity

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

CPE Weekly: 2019-12-06

2019-12-06 Thread Aoife Moloney

Hi everyone,


Welcome to the CPE team weekly project update mail!



Background:

The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Our goal is to keep
core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers
can give.

For better communication, we will be giving weekly reports to the
CentOS and Fedora communities about the general tasks and work being
done.  Also for better communication between our groups we have
created #redhat-cpe on Freenode IRC! Please feel free to catch us
there, a mail has landed on both the CentOS and Fedora devel lists
with context here.


Note:

This document is currently built from individual reports rolled into a
google document which we edit and copy into a final document. We are
aware that this causes problems with some email readers, and are
working on a method to make this less problematic.


High Level Project Updates:




Fedora:


OSBS : aarch64 hosts ready for the deployment of an OpenShift cluster.

https://pagure.io/fedora-infrastructure/issue/8442


The Community Fire Team (CFT) is a team of people dedicated to fixing
bugs, annoyance and (small) RFE all around our applications. Their
work is tracked in taiga at:
https://teams.fedoraproject.org/project/community-fire-team/kanban and
they use #fedora-apps for discussion and coordination.

As usual, anyone is welcome to join the team, for a day, a task or more!


This week CFT has achieved the following work:

Release and deploy pagure 5.8.1

Changelog at: https://docs.pagure.org/pagure/changelog.html#id1

Release and deploy pagure-dist-git 1.5.2

Fixes enabling the pull-request only workflow on dist-git

Fix getting the CI pipeline results to show on PR on dist-git

Fix the script syncing the default assignee and CC list from dist-git
to bugzilla

So far there were no negative feedback about the changes this script will do

Deploy the script syncing default assignee and CC list from dist-git
to bugzilla on openshift in staging


And is actively working on:

Enabling side-tag based updates in stable releases

Adding a new API endpoint to pagure to enable/disable git hooks

Adding tests for the fedora-messaging support in the JMS plugin (used
by ci.centos.org)

Making ansible-review work with the infrastructure's ansible repository

Fixing the mdapi integration on dist-git's package page




F31 Updates

 kojipkgs01/02 has been reinstalled

Robosign config for fcos has been updated


Rawhide Gating:

Team still welcomes any input and feedback on your experience with
Rawhide Gating to date as we move through our testing ahead of making
it generally available


Bodhi



Application Retirements


Elections

Elections are ready to be moved to Communishift!

The move will be planned after the current elections are over.

Fedocal

Still no progress on kanban board last six weeks
https://teams.fedoraproject.org/project/fedora-calendar/kanban

Jlanda’s permission error in communishift should now be fixed
https://pagure.io/fedora-infrastructure/issue/8274

There may be still another permission error so the team are investigating

Still working on running local instance

Nuancier

Benson Muite is now working on OIDC authentication

A PR will be created on Github to test if we can see the progress

New PR from sebwoj - Porting to Fedora messaging is under review

Autocloud retired

Tests of cloud images moved to openqa

Retired vm’s and removed from ansible

Turning bare metal nodes into builders.



Fedora Docs Updates

Open Tickets:

https://pagure.io/Ask-Fedora-SOP-docs/issue/7

https://pagure.io/fesco/fesco-docs/pull-request/21

Merges:

https://pagure.io/fedora-docs/quick-docs/pull-request/164

Fixes:

https://pagure.io/fedora-docs/docs-fp-o/issue/111





CentOS:


Migrated this week (new pkg, new ansible-role):

Torrent.centos.org

Ipv6.torrent.centos.org

Prepared to be migrated next week:

Wiki.centos.org

Kicked off : new ansible roles in progress for :

Bind to support dynamic delegated zone for acme dns-challenge

Mailman and postfix

CentOS Stream

We have our first compose gone to Red Hat Internal QA for testing

Other work still progressing on the builders





Misc


Koji production is upgraded to 1.19.1

Bodhi builds are now based on git

Changes added to Bodhi to add support for side-tags in stable releases
are pending reviews

https://github.com/fedora-infra/bodhi/pull/3749

https://github.com/fedora-infra/bodhi/pull/3761

https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/35


Email with the Bugzilla-distgit sync script changes have been sent to
devel-announce for review

Link to mail

New changes to Pagure pending review:

New API endpoint to enable/disable git hooks

Ability to set dist-git in the default assignee overrides for bugzilla

Direct API interface

Button on the pagure package web interface


EPEL 8 modularity

Bodhi composes are

[Bug 1779900] perl-Archive-Extract-0.84 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Archive-Extract-0.84-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-5512be361d

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Test-Announce] 2019-12-09 @ 16:00 UTC - Fedora QA Meeting

# Fedora Quality Assurance Meeting
# Date: 2019-12-09
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

We have a couple of active proposals to discuss, so let's get together
on Monday and check in.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Proposed asynchronous blocker review process
3. Proposed disk unmount test case
4. F31 eclipse module default stream / protobuf issue
5. Test Day / community event status
6. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular protobuf issue (Dec. 6, 2019) recap

2019-12-06 Thread Ben Rosser

On Fri, Dec 6, 2019 at 8:19 PM Langdon White  wrote:
> ## What happened:
> First and foremost, this issue appears to be caused by Modularity but, in 
> fact, is just an example of a policy not being followed. When a module wishes 
> to declare a "default stream"[1] it *must* not override a traditional RPM 
> without express permission from FESCo. The policy is documented here[2].
>
> Unfortunately, the recent change to enable an Eclipse Module Stream as a 
> default stream did not follow this policy and provided a different protobuf 
> RPM with different functionality.
>
> ## What we can do going forward:
> * Increase the awareness of the policies for Fedora Modules
> * Investigate an "early warning system" that would indicate to packagers 
> (modular and RPM) when they might be violating this policy

Hi Langdon,

Thanks for the summary of the issue.

Igor wrote in the other thread that, as the maintainer of protobuf, he
had no idea this was happening. In addition to FESCo approval, is it
worth stating explicitly somewhere in the policy that overriding a
traditional RPM should require the consent of the maintainer(s) of
that RPM?

(I realize that in this particular case, Igor is on FESCo, and so had
the policy been followed more carefully, he would have been aware
anyway).

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular protobuf issue (Dec. 6, 2019) recap


On 07. 12. 19 2:18, Langdon White wrote:
First and foremost, this issue appears to be caused by Modularity but, in fact, 
is just an example of a policy not being followed. When a module wishes to 
declare a "default stream"[1] it *must* not override a traditional RPM without 
express permission from FESCo. The policy is documented here[2].


To clarify: The default modular stream of eclipse was approved by FESCo (and it 
was known that it would override traditional packages), but it was approved 
based on incomplete information.


The need for the default stream however, was caused by other default modular 
streams violating this policy.


Is this the right time to remove such default modular streams?

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

Re: modular protobuf issue (Dec. 6, 2019) recap

On Fri, 2019-12-06 at 20:18 -0500, Langdon White wrote:
> ## How to determine if you have an issue and how to fix it:
> 
> run: ```sudo dnf list --installed *protobuf*```
> if you get a result that looks like
> ```protobuf.x86_64  3.6.1-6.module_f31+6793+1c93c38```
> 
> you have encountered the problem. so please:
> 
> run: ```sudo dnf module disable eclipse```
> run:  ```sudo dnf downgrade protobuf```
> 
> Any updates, as of a few hours ago, should be fine.

I really think we should recommend 'dnf distro-sync', assuming it
actually does the job, as that should return *all* installed packages
from the newly-disabled modules to the non-modular builds, not just
protobuf.
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

On Fri, 2019-12-06 at 18:51 -0600, Richard Shaw wrote:
> After reading this thread I think this is a more serious problem than just
> this package. I had "assumed" modules were just normal, so I didn't
> question them being installed.

They are normal. You're not wrong. The problem is well understood at
this point: a module was given a stream default - meaning it becomes
the default source of packages it contains. That module includes
protobuf, meaning it takes over from the non-modular repo as the
default source of protobuf. The build of protobuf it contains was
missing some bits that other packages depend on, which broke those
packages.

> I have not intentionally enabled/installed any modules but through regular
> updates I now have the following installed:

Well, yes. That's what happens. If this didn't actually break anything
for you, you don't really need to panic, but if you want to sync with
the current state (where the module stream default has been removed at
least temporarily), just disable the modules that were enabled and then
run 'dnf distro-sync'. That should return you to the non-modular
builds.
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

modular protobuf issue (Dec. 6, 2019) recap

2019-12-06 Thread Langdon White

## How to determine if you have an issue and how to fix it:

run: ```sudo dnf list --installed *protobuf*```
if you get a result that looks like
```protobuf.x86_64  3.6.1-6.module_f31+6793+1c93c38```

you have encountered the problem. so please:

run: ```sudo dnf module disable eclipse```
run:  ```sudo dnf downgrade protobuf```

Any updates, as of a few hours ago, should be fine.

## What happened:
First and foremost, this issue appears to be caused by Modularity but, in
fact, is just an example of a policy not being followed. When a module
wishes to declare a "default stream"[1] it *must* not override a
traditional RPM without express permission from FESCo. The policy is
documented here[2].

Unfortunately, the recent change to enable an Eclipse Module Stream as a
default stream did not follow this policy and provided a different protobuf
RPM with different functionality.

## What we can do going forward:
* Increase the awareness of the policies for Fedora Modules
* Investigate an "early warning system" that would indicate to packagers
(modular and RPM) when they might be violating this policy
* Request dnf notify the user when they are enabling a superseding rpm from
a default stream module
* Request dnf provide an indication of what module is providing a
particular rpm (e.g. `dnf provides protobuf` not just indicate repo origin
but also module name and stream)

Langdon

[1]: if you are unfamiliar, this is the functionality that allows a module
stream to be used transparently by end users without them needing to
explicitly install a module.
[2]:
https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-defaults/#_setting_or_changing_a_default
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

Problem solved...

It is possible to resolve the problem without rolling back updates.

$ rpm -qa | grep module_ | xargs sudo dnf -y erase
$ sudo dnf module disable \*
$ sudo install 

I'm guessing you could skip the first and last and just disable the modules
and do a distro-sync?

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

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

Charalampos Stratakis wrote:
>> From: "Miro Hrončok" 
>> On 06. 12. 19 18:10, Charalampos Stratakis wrote:
>> >> > Or do we need to rollback the update?
>> 
>> Rollback or disable explicitly.
> 
> That is more than unfortunate.

IMHO, we should disable all default module streams in F31 immediately and at 
the same time push a DNF update to F31 updates that disables ALL module 
streams. Then users can explicitly reenable those that they actually want 
and that were not forced on 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

Ok, even worse than I thought, if I try to remove all the modules it wants
to take these packages with it...

Removing dependent packages:
 OpenImageIO-utils   x86_64
2.0.11-1.fc31  @updates
 2.1 M
 clementine  x86_64
1.3.1-38.20181130gitd260c8b.fc31   @fedora
   23 M
 jackson-module-mrbean   noarch
2.10.0-1.fc31  @updates
  37 k
 libreoffice-writer2latexx86_64
1.0.2-26.fc31  @fedora
  505 k
 mlt x86_64
6.18.0-1.fc31  @updates
 3.1 M
 nomacs  x86_64
3.12-1.fc31@fedora
  7.9 M
 opencv  x86_64
3.4.8-1.fc31   @updates
  11 M
 pentaho-reporting-flow-engine   noarch
1:0.9.4-18.fc31@fedora
  428 k
 vlc x86_64
1:3.0.9-22.fc31
 @rpmfusion-free-updates   5.5 M
Removing unused dependencies:
 OpenImageIO x86_64
2.0.11-1.fc31  @updates
  12 M
 flute   noarch
1.3.0-21.OOo31.fc31@fedora
   62 k
 libbase noarch
1.1.3-22.fc31  @fedora
  147 k
 libfontsnoarch
1.1.3-25.fc31  @fedora
  255 k
 libformula  noarch
1.1.3-22.fc31  @fedora
  416 k
 liblayout   noarch
0.2.10-19.fc31 @fedora
  841 k
 libloader   noarch
1.1.3-21.fc31  @fedora
  130 k
 libmicrodns x86_64
0.0.10-4.fc31  @fedora
   56 k
 libplacebo  x86_64
1.18.0-2.fc31  @fedora
  3.1 M
 librepository   noarch
1.1.3-21.fc31  @fedora
   85 k
 libserializer   noarch
1.1.2-22.fc31  @fedora
   50 k
 movit   x86_64
1.6.2-4.fc31   @fedora
  795 k
 movit-data  noarch
1.6.2-4.fc31   @fedora
   44 k
 opencv-contrib  x86_64
3.4.8-1.fc31   @updates
  20 M
 opencv-core x86_64
3.4.8-1.fc31   @updates
  26 M
 openni  x86_64
1.5.7.10-16.fc31   @fedora
  1.6 M
 pentaho-libxml  noarch
1.1.3-21.fc31  @fedora
  107 k
 vlc-corex86_64
1:3.0.9-22.fc31
 @rpmfusion-free-updates50 M

WTF?

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

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

After reading this thread I think this is a more serious problem than just
this package. I had "assumed" modules were just normal, so I didn't
question them being installed.

I have not intentionally enabled/installed any modules but through regular
updates I now have the following installed:

$ rpm -qa | grep module_
xml-commons-resolver-1.2-26.module_f28+3872+5b76729e.noarch
jaf-1.2.1-3.module_f31+5559+ae1ed734.noarch
jzlib-1.1.3-8.module_f28+3872+5b76729e.noarch
bouncycastle-pg-1.61-1.module_f31+6165+9b01e00c.noarch
apache-commons-codec-1.11-3.module_f29+6921+ca3ed728.noarch
jakarta-commons-httpclient-3.1-31.module_f31+6165+9b01e00c.noarch
log4j12-1.2.17-22.module_f28+3872+5b76729e.noarch
javamail-1.6.3-4.module_f31+5559+ae1ed734.noarch
xerces-j2-2.11.0-34.module_f28+3872+5b76729e.noarch
jline-2.14.6-4.module_f31+6165+9b01e00c.noarch
eclipse-equinox-osgi-4.12-6.module_f31+6165+9b01e00c.x86_64
protobuf-3.6.1-6.module_f31+6165+9b01e00c.x86_64
jackson-databind-2.9.8-1.module_f31+6165+9b01e00c.noarch
jansi-native-1.7-7.module_f29+6921+ca3ed728.x86_64
jackson-annotations-2.9.8-1.module_f31+6165+9b01e00c.noarch
apache-commons-net-3.6-3.module_f28+3872+5b76729e.noarch
hawtjni-runtime-1.16-2.module_f29+6921+ca3ed728.noarch
sac-1.3-30.module_f31+6165+9b01e00c.noarch
apache-commons-logging-1.2-13.module_f29+6921+ca3ed728.noarch
objectweb-asm-7.0-2.module_f31+6165+9b01e00c.noarch
jna-4.5.1-9.module_f31+6165+9b01e00c.x86_64
xml-commons-apis-1.4.01-25.module_f28+3872+5b76729e.noarch
xalan-j2-2.7.1-38.module_f28+3872+5b76729e.noarch
jansi-1.17.1-1.module_f29+6921+ca3ed728.noarch
protobuf-lite-3.6.1-6.module_f31+6165+9b01e00c.x86_64
jsch-0.1.54-7.module_f28+3872+5b76729e.noarch
apache-commons-lang3-3.7-3.module_f29+6921+ca3ed728.noarch
protobuf-compiler-3.6.1-6.module_f31+6165+9b01e00c.x86_64
bouncycastle-1.61-1.module_f31+6165+9b01e00c.noarch
rxtx-2.2-0.24.20100211.module_f31+6165+9b01e00c.x86_64
rhino-1.7.7.1-7.module_f31+6165+9b01e00c.noarch
gimp-libs-2.10.14-1.module_f31+6993+669d73be.x86_64
jackson-core-2.9.8-2.module_f31+6165+9b01e00c.noarch
gimp-2.10.14-1.module_f31+6993+669d73be.x86_64
apache-commons-compress-1.18-6.module_f31+6165+9b01e00c.noarch

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

Re: Allow comments and discussion even though an update was pushed to stable

Fabio Valentini wrote:
> Right. So should the default of -3/+3 be changed for "critpath" packages?
> They already need 14 days in testing, but they also get orders of
> magnitude more feedback, so raising the karma limits to -2/+6 or something
> like that sounds reasonable to me.
> 
> On the other hand, I wouldn't even have any objections to changing the
> defaults to something like -2/+6 for all packages, since it wouldn't make
> any difference at all for the majority of packages that reach 7 days in
> testing without any feedback whatsoever.

IMHO, packages should just not be autopushed at all, no matter what 
threshold. An update can have +2 karma and be perfectly good to push, or it 
can have +10 karma and still have issues. It depends on what the users 
actually tested. So the maintainer should always read the freeform feedback 
text and decide based on that. (In fact, I would abolish the numeric karma 
entirely, provide only the freeform text field for feedback, and let the 
maintainer decide after reading it all. Humans will always make better 
decisions than naïve algorithms. But IMHO, even if the minimum karma 
requirement of +1 or 7 days wait time for non-critpath and +2 or 14 days 
wait time for critpath remains unchanged, it would still be an improvement 
to not allow automatic pushes of any kind.)

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: OCaml 4.09.0 rebuild complete in Rawhide (was: Re: OCaml 4.09.0 will be added to Fedora 32 via a side tag)

2019-12-06 Thread Jerry James

On Fri, Dec 6, 2019 at 5:12 PM Kevin Fenzi  wrote:

> This looks like a bug in the koji sidetag plugin that rawhide multibuild
> uses.
>
> Can someone file a ticket at
> https://pagure.io/sidetag-koji-plugin/issues ?
>

https://pagure.io/sidetag-koji-plugin/issue/11

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Lennart Poettering wrote:
> If you know where stuff is located you can change individual blocks in
> files. You are not going to know what you are changing them to, but
> you can change it and traditional files will not detect that you did that.

Then you get unpredictable garbage as the result, which is useless if your 
goal (as the attacker) is to plant a trojan horse that steals encrypted data 
while it is decrypted. (And of course, you cannot directly decrypt the data 
either.) The only way to exfiltrate the data is to attack the system while 
it is running (online).

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Marius Schwarz wrote:
> "Figure out intersection with current work to use the TPM to allow
> booting to GDM without entering the password."
> 
> Means, if someone steals the device, he can boot a system.

And conversely, if you move the hard disk to another computer, you can no 
longer read it. And if your motherboard breaks down, instant data loss.

In addition, I do not trust the TPM or any other Treacherous Computing 
component.

If you want to rely on a hardware key, it should at least be on a removable 
USB token (a keyfile on a plain mass-storage USB stick is enough!), not 
hard-wired into the computer like the TPM.

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: OCaml 4.09.0 rebuild complete in Rawhide (was: Re: OCaml 4.09.0 will be added to Fedora 32 via a side tag)

2019-12-06 Thread Kevin Fenzi

On Fri, Dec 06, 2019 at 04:14:12PM -0700, Jerry James wrote:
> On Fri, Dec 6, 2019 at 9:31 AM Richard W.M. Jones  wrote:
> 
> > A few non-critical packages failed to build, and I will look at these
> > later unless someone gets around to it before me.  The failures are
> > listed at the end.
> >
> [snip]
> 
> > ocaml-tplib
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1420345
> >
> 
> I am trying to look at this, but after clicking through to the task page:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=39451983
> 
> I cannot get to any of the builds.  It looks like only the ppc64le build
> failed, but clicking on any of them, failed or not, results in a page that
> says:
> 
> Error
> An error has occurred while processing your request.
> NotFound: cannot find 'name' while searching for 'buildTag.name'
> 
> Full tracebacks disabled
> 
> 
> Does anybody know what is going on with that?

This looks like a bug in the koji sidetag plugin that rawhide multibuild
uses. 

Can someone file a ticket at
https://pagure.io/sidetag-koji-plugin/issues ?

kevin


signature.asc
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Chris Murphy wrote:
> Is it your position that encrypting ~/ alone is not an incremental
> improvement? Are you suggesting it's necessary to assume Fedora
> Workstation users are subject to targeted attacks? And therefore
> install time default must encrypt /, /home, swap? And that this
> targeted attack, that applies to everyone, does not include targeted
> attacks on unencrypted /boot or the bootloader for reasons you refuse
> to elaborate on?

Anaconda should encrypt /boot too. Calamares does it. GRUB supports 
prompting for a LUKS passphrase and decrypting LUKS with it. LUKS 1 has been 
supported by GRUB for a while (so Calamares still uses that for now), and 
there is now a patchset under review for LUKS 2 support:
https://lists.gnu.org/archive/html/grub-devel/2019-11/msg0.html

Then (in the Calamares setup) the other partitions are unlocked 
automatically using a keyfile residing on the encrypted /boot, so that the 
user has to enter the passphrase only once (in GRUB).

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Chris Murphy wrote:
> Hibernation is out of scope to rely on, let alone make a default, for
> at least the following reasons:
[snip]
> b. It's disabled by kernel lockdown on UEFI Secure Boot systems.

This, in fact, is one more reason to disable Restricted Boot first thing, 
before doing anything else with YOUR computer. Because with Restricted Boot, 
it is effectively NO LONGER YOUR computer.

The fact that this "security" model is inherently incompatible with features 
as common and as frequently used as hibernation and that the "remedy" is to 
disallow the user from using those features shows that this model is 
inherently flawed and unacceptable for a Free Software operating system.

Treacherous computing needs to stop! Reclaim your computer! The user should 
own the computer, not the other way round!

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Issue with Fedora GeoIP service

2019-12-06 Thread Kevin Fenzi

On Fri, Dec 06, 2019 at 04:49:15PM +, Tom Hughes wrote:
> On 06/12/2019 16:41, Martin Kolman wrote:
> > On Fri, 2019-12-06 at 08:38 -0600, Chris Adams wrote:
> > 
> > > I also installed the Fedora 31 GeoIP packages and ran the geoipupdate,
> > > and that DB has the correct info.
> >
> > IIRC the infra team mentioned some issues with the new geoip database
> > being incompatible with how the service is currently implemented,
> > resulting in being stuck with an outdated database until this is resolved.
> 
> Sounds like it maybe doesn't have support for GeoLite2 and is using the
> old MaxMind GeoLite Legacy databases which haven't been updated since
> the start of this year.

Yes, that is exactly the case. 

We recently looked at this to see if we could retire the service, but it
looks like it's still needed, so we need to figure out how to get cycles
to update it. 

If someone wants to work on this, let us know!

kevin


signature.asc
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Felix Schwarz


Am 06.12.19 um 23:45 schrieb Charalampos Stratakis:

I get there might be some quirks here and there, but having that done on a 
stable fedora due to eclipse moving into a module so late in the release cycle 
is just unacceptable. I don't know what a good solution would be here, maybe 
have eclipse as a flatpak only or something, but this is clearly breaking user 
experience and expectations.


To me the worst thing is that we have no way of fixing that error without user 
interaction because the current modularity tooling/design does not allow this.


I mean errors happen but for regular packages we can remove faulty packages by 
obsoleting them or bumping the epoch.


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

Re: OCaml 4.09.0 rebuild complete in Rawhide (was: Re: OCaml 4.09.0 will be added to Fedora 32 via a side tag)

2019-12-06 Thread Jerry James

On Fri, Dec 6, 2019 at 9:31 AM Richard W.M. Jones  wrote:

> A few non-critical packages failed to build, and I will look at these
> later unless someone gets around to it before me.  The failures are
> listed at the end.
>
[snip]

> ocaml-tplib
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1420345
>

I am trying to look at this, but after clicking through to the task page:

https://koji.fedoraproject.org/koji/taskinfo?taskID=39451983

I cannot get to any of the builds.  It looks like only the ppc64le build
failed, but clicking on any of them, failed or not, results in a page that
says:

Error
An error has occurred while processing your request.
NotFound: cannot find 'name' while searching for 'buildTag.name'

Full tracebacks disabled


Does anybody know what is going on with that?
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Charalampos Stratakis



- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, December 6, 2019 6:12:32 PM
> Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for 
> protobuf
> 
> On Fri, Dec 6, 2019 at 12:11 PM Charalampos Stratakis
>  wrote:
> >
> >
> >
> > - Original Message -
> > > From: "Stephen Gallagher" 
> > > To: "Development discussions related to Fedora"
> > > 
> > > Cc: "Mat Booth" ,
> > > protobuf-mainatin...@fedoraproject.org
> > > Sent: Friday, December 6, 2019 5:59:50 PM
> > > Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for
> > > protobuf
> > >
> > > On Fri, Dec 6, 2019 at 11:51 AM Igor Gnatenko
> > >  wrote:
> > > >
> > > > Thanks for CCing me (maintainer of protobuf here), I am particularly
> > > > not happy that some module (which is not even called protobuf, but
> > > > some random Java #$%! with ripped out python support overrides my
> > > > builds).
> > > >
> > > > I have put a proposal into a FESCo ticket.
> > > >
> > > > On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok 
> > > > wrote:
> > > > >
> > > > > Today I've attempted to run "dnf upgrade".
> > > > >
> > > > > It has the following in it:
> > > > >
> > > > > Upgrading:
> > > > > protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
> > > > >
> > > > > Enabling module streams:
> > > > >   ant
> > > > >   eclipse
> > > > >   maven
> > > > >
> > > > >
> > > > > I don't consider this behavior adequate for a released Fedora
> > > > > version.
> > > > >
> > > > > As a maintainer of dependent packages (Cura stack) I have tested and
> > > > > built it
> > > > > against the nonmodular protobuf. What just happened here and how do I
> > > > > track it down?
> > > > >
> > > > > dnf doesn't even tell me what module is this in. I suppose eclipse.
> > > > >
> > > > > However, protobuf was not mentioned in
> > > > > https://pagure.io/fesco/issue/2285
> > > > >
> > >
> > >
> > > For the record, I've just pushed a temporary removal of the eclipse
> > > default stream, so the next compose will not have it. For those of you
> > > who are affected, your best bet would be to use `yum history rollback`
> > > and wait to update again until tomorrow.
> >
> > I got affected as well and I guess a big number of people also.
> >
> > Is it safe to assume that with the next compose the extra modules will be
> > disabled/removed when doing a dnf update? Or do we need to rollback the
> > update?
> >
> 
> No, the extra modules won't be disabled/removed automatically. The
> change I made is to ensure no one else gets hit. You will need to roll
> back the update if you were affected.

I would like to mention here that this is the first time that a modularity 
issue affected me negatively as a user.

I maintain a quite pristine system with fedora 31 on my home computer, knowing 
full well, exactly what is installed, dependencies, configs etc. And at some 
point while doing the schedule dnf update I get 3 modules enabled for whatever 
reason that I had no control over. No information, nothing.

I get there might be some quirks here and there, but having that done on a 
stable fedora due to eclipse moving into a module so late in the release cycle 
is just unacceptable. I don't know what a good solution would be here, maybe 
have eclipse as a flatpak only or something, but this is clearly breaking user 
experience and expectations.

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

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Allow comments and discussion even though an update was pushed to stable

On Fri, 2019-12-06 at 20:51 +, Johannes Lips wrote:
> > "Johannes Lips"  > 
> > 
> > We already have a tool for reporting issues and problems, and it's not
> > bodhi.  If there's a problem with an already pushed update, it needs to
> > be in bugzilla - where it's actually discoverable - not in bodhi, where
> > it will go nowhere.
> I am not intending to use bodhi as a bug tracker, but I would like to be able 
> to reference issues, which were introduced with an update and I don't really 
> see a lot of negative effects of this.
> I think it's a way to make issues in bugzilla more easily traceable, since if 
> an update is closely related with a new bug it is easier to just look into 
> bodhi first and see if the issue affected others as well. If by chance the 
> first reporter of a bug is too late in bodhi this connection is simply lost.
> I don't see it as bodhi replacing bugzilla, but rather as an additional entry 
> point, when looking for known issues in close relation with a bug.

FWIW, there is in fact an open Bodhi ticket for this:

https://github.com/fedora-infra/bodhi/issues/3748

which references the earlier ticket that requested comments be
disallowed on stable updates:

https://github.com/fedora-infra/bodhi/issues/2050
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-06 Thread Chris Murphy

On Fri, Dec 6, 2019 at 9:41 AM John M. Harris Jr  wrote:
>
> On Friday, December 6, 2019 8:27:32 AM MST Marius Schwarz wrote:

> > "Figure out intersection with current work to use the TPM to allow
> > booting to GDM without entering the password."
> >
> > Means, if someone steals the device, he can boot a system. Even if we
> > assume that the systemcode is safe and there is no way to interrupt the
> > bootprocess, we are now able to attack the login, which will be much
> > easier than the encryption key, which is massive compared to the
> > passwords in use.
>
> Yeah, there are a contingent here that believe that it's not necessary to
> ensure the person booting the device is actually authorized to access the
> content of the laptop..

Is it your position that encrypting ~/ alone is not an incremental
improvement? Are you suggesting it's necessary to assume Fedora
Workstation users are subject to targeted attacks? And therefore
install time default must encrypt /, /home, swap? And that this
targeted attack, that applies to everyone, does not include targeted
attacks on unencrypted /boot or the bootloader for reasons you refuse
to elaborate on? And you propose that users should have to opt out of
this, rather than opt in?

> And, because it makes things "easy" for the user, I get the feeling something
> like this will wind up getting implemented. Oh well.

It's already implemented. There is no encryption by default.

You've set up a false dilemma where the only two valid options are do
nothing and do what you want. You reject all intermediate options,
dismissing them out of turn without any meaningful evaluation. And
that's on top of having said you are unconcerned with GNOME and don't
care about the outcome. If you don't care, why are you still arguing?

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-06 Thread Przemek Klosowski via devel


On 12/6/19 11:40 AM, John M. Harris Jr wrote:

Means, if someone steals the device, he can boot a system. Even if we
assume that the systemcode is safe and there is no way to interrupt the
bootprocess, we are now able to attack the login, which will be much
easier than the encryption key, which is massive compared to the
passwords in use.

Yeah, there are a contingent here that believe that it's not necessary to
ensure the person booting the device is actually authorized to access the
content of the laptop..


Which threat model do you consider here? I don't remember anyone 
suggesting that the person who physically boots the machine gets 
unimpeded access to the contents, without any authentication: the 
assumption is that system boots into an authentication login prompt.


We discussed the following threats:

- removing the physical unencrypted (or encrypted) disk, and reading and 
even modifying it in another system


- interrupting the boot process and bypassing authentication

- bypassing or bruteforcing the login authentication (Marius' concern)

Each threat requires a different mitigation. The Android model depends 
on the fact that the storage media is not easily removable, and is 
encrypted with securely stored keys (a la TPM), and the fact that the 
boot process is secure so you can't break into it after the storage is 
decrypted, so then the remaining threat vector is breaking the user 
login authentication shown when the system completes the boot process.


At some point you said that you don't believe that Android model is 
secure -- could you explain why do you believe that? This is relevant to 
our discussion because I believe that we should follow the Android/IOS 
model.


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

Re: Allow comments and discussion even though an update was pushed to stable

2019-12-06 Thread Johannes Lips

> "Johannes Lips"  
> 
> We already have a tool for reporting issues and problems, and it's not
> bodhi.  If there's a problem with an already pushed update, it needs to
> be in bugzilla - where it's actually discoverable - not in bodhi, where
> it will go nowhere.
I am not intending to use bodhi as a bug tracker, but I would like to be able 
to reference issues, which were introduced with an update and I don't really 
see a lot of negative effects of this.
I think it's a way to make issues in bugzilla more easily traceable, since if 
an update is closely related with a new bug it is easier to just look into 
bodhi first and see if the issue affected others as well. If by chance the 
first reporter of a bug is too late in bodhi this connection is simply lost.
I don't see it as bodhi replacing bugzilla, but rather as an additional entry 
point, when looking for known issues in close relation with a bug.

Johannes
> 
> From the other side, as a maintainer, it is important to have as few
> channels for reporting issues as possible.  Keeping everything in one
> place is important so nothing gets lost, and it all can be queried and
> triaged appropriately.
> 
> Please do not use bodhi as a bug reporting tool.
> 
> Thanks,
> --Robbie
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Charalampos Stratakis



- Original Message -
> From: "Miro Hrončok" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, December 6, 2019 6:13:08 PM
> Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for 
> protobuf
> 
> On 06. 12. 19 18:10, Charalampos Stratakis wrote:>> For the record, I've just
> pushed a temporary removal of the eclipse
> >> default stream, so the next compose will not have it. For those of you
> >> who are affected, your best bet would be to use `yum history rollback`
> >> and wait to update again until tomorrow.
> > 
> > I got affected as well and I guess a big number of people also.
> > 
> > Is it safe to assume that with the next compose the extra modules will be
> > disabled/removed when doing a dnf update?
> 
> As of the moment, once a modular stream is enabled implicilty, there is no
> way
> to disable it implicitly.
> 
> > Or do we need to rollback the update?
> 
> Rollback or disable explicitly.

That is more than unfortunate.

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

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

On Fri, 2019-12-06 at 14:05 -0500, Stephen Gallagher wrote:
> On Fri, Dec 6, 2019 at 1:52 PM Alexander Ploumistos
>  wrote:
> > On Fri, Dec 6, 2019 at 6:14 PM Miro Hrončok  wrote:
> > > Rollback or disable explicitly.
> > 
> > I had been busy testing a bunch of other packages from koji and
> > rollback is going to break a lot of things at this point.
> > Could you please explain how to install the new protobuf build and get
> > rid of the pulled-in dependencies (in a way that people with
> > overworked and under-functioning brain cells could understand)?
> 
> In theory, `dnf module disable eclipse` and `dnf downgrade protobuf`
> should work. I haven't tried this myself.

Maybe distro-sync rather than downgrade protobuf would be better?
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-06 Thread Chris Murphy

On Fri, Dec 6, 2019 at 8:28 AM Marius Schwarz  wrote:
>
> Am 05.12.19 um 23:02 schrieb Chris Murphy:
>
> read "LUKS by default"
>
> https://pagure.io/fedora-workstation/issue/82
>
> If you read the whole thing, you should come to understand why the
> initial agreement to implement full disk encryption was suspended, and
> also that this issue has a history proving it is being taken seriously
> and deliberately.
>
>
> First paragraph:

I suggested reading the entire thread, not pulling it apart. If you
want to do that please start a new thread.

> "Figure out intersection with current work to use the TPM to allow booting to 
> GDM without entering the password."
>
> Means, if someone steals the device, he can boot a system. Even if we assume 
> that the systemcode is safe and there is no way to interrupt the bootprocess, 
> we are now able to attack the login, which will be much easier than the 
> encryption key, which is massive compared to the passwords in use.
>
> So, NO: no booting without someone entering something.
>
> Besides the already spoken out point, that not all users want encryption, 
> because it takes into consideration to manage an additional passcode,
> the entire discussion here was about "encrypt everything, or nothing, because 
> partly does not help at all".

This is not correct. /home only encryption is part of that discussion:
this includes a single home volume mounted at /home with a single LUKS
DEK, one or more KEKs (user passphrase stored in LUKS keyslot), as
well as individual separately encrypted ~/ per user.

Your position as stated is absurd because it assumes a compromised
system is inevitable in one case but not the other. Case 1 is ~/ only
is encrypted, and your assertion is that this does *not help at all*
improve user data confidentiality on the basis that without / and swap
being encrypted that ~/ is vulnerable to a targeted attack via / or
swap being compromised. Case 2 is present day Fedora "full disk
encryption" which does not lock down the bootloader,  /boot volume is
not encrypted, and thus the initramfs is vulnerable to a targeted
attack which could be used to deploy a key logger or whatever you're
worried about in Case 1.

It is not valid to use different goal posts for the different cases
under comparison. Right now Fedora's default is no encryption at all,
and the way you've worded your assertion, you propose user data would
become more susceptible to attack or exfiltration if ~/ alone is
encrypted. That must be hyperbole so I insist that you do a better job
of constraining your assertions to things we can all agree on.

Otherwise you are invited to describe exactly how encrypted ~/ alone
makes the user worse off than today's default, which is encrypting
nothing. Because that is the more valid comparison: what we are doing
now, versus what we should do as a next logical step. The next logical
step is not the final step, it probably will be a baby step. So try
not to get carried away with unrealistic demands for which resources
don't exist. Whatever happens requires a plan.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Working fedora-active-user script?

2019-12-06 Thread Pierre-Yves Chibon

On Fri, Dec 06, 2019 at 01:52:52PM -0600, Richard Shaw wrote:
>First, done anyone have a working version of the script? Google returns
>the github page which hasn't been updated in 3 years and currently fails
>trying to import the 'fedora_cert' module.

There is a PR submitted that fixes most the issue but also changes the way email
archives are checked and making that feature not working (the last time I've
tried it).
I'll try to get some time, maybe next week or the following one to clean it up
and update it a bit.

>Secondly, how is this not in a package yet? It's an extremely useful tool
>for determining if initiating the non-responsive maintainer process.

Oh there is an easy answer for that: nobody did it :)


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

Working fedora-active-user script?

First, done anyone have a working version of the script? Google returns the
github page which hasn't been updated in 3 years and currently fails trying
to import the 'fedora_cert' module.

Secondly, how is this not in a package yet? It's an extremely useful tool
for determining if initiating the non-responsive maintainer process.

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

Re: Fedora without compressed instruction support

2019-12-06 Thread David Abdurachmanov

On Thu, Dec 5, 2019 at 12:30 PM Billa Surendra
 wrote:
>
> Dear David Abdurachmanov,
>
> I have seen your presentation about fedora bootstrap on RV64, it was very 
> nice presentation actually. I am planning to boot a RISC-V Fedora on QEMU 
> Emulator, but I want to do some changes in fedora distro. Fedora distro 
> without compressed instruction support require for me, for this I have 
> written some steps where I can do changes. This steps completely I have taken 
> from your presentation. Please correct my steps whether I am going in correct 
> way or not ? I am new to fedora as well as bootstrap process.

Hi,

Did you have time to look into my previous email? It outlines the
ideas/step how to do it.

>
> Steps:
>
> 1. Installing QEMU (In x86 fedora host PC)
> 2. Installing GNU cross compiler tool chain (In this step I have installed 
> tool chain https://github.com/riscv/riscv-gnu-toolchain (RV64IMAFD support) 
> in fedora 86 host PC).
> 3. Install Berkly bootloader (In this step I have installed bootloader 
> https://github.com/riscv/riscv-pk in fedora x86 host pc).
> 4. Linux kernel + basic rootfs (In this step taken Linux kernal from 
> https://www.kernel.org/ and cross compiled with above tool chain, created 
> basic rootfs).

You don't need to do this:
- Don't use https://github.com/riscv/riscv-gnu-toolchain This is old
and all development moved to a proper upstream location.
- BBL was replaced by OpenSBI. I would highly advice to avoid BBL.
Fedora/RISCV use OpenSBI and BBL is deprecated.
- Fedora/RISCV supports RV64GC, but you can run (should be able) RV64G
binaries. The latest time I checked glibc will missing DSO (RV64GC and
RV64G). That does not affect the ABI.

Simply put you need to take Fedora/RISCV disk image and recompile
toolchain to target RV64G. Then start rebuilding all the packages.
Finally you assemble a new disk image using your built packages.

>
>
> From Here I am not understanding the steps
>
> 5. Cross compile  and Install "RPM" packages and dependencies (where I can 
> get RPMs and dependencies list, after cross compiling RPMs whare I have to 
> install ?).
> 6. Install pre build RPMS (no idea about this step).
> 7. Rebuild RPMS from SRPMs natively (no idea about this step).
> 8. Install the new RPMS (no idea about this step).
> 9. Build stage4 image (no idea about this step).
>
> Please correct my steps and give the solutions for step (5-9).
>
> Thanks
>
> Billa
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Alexander Ploumistos

On Fri, Dec 6, 2019 at 8:06 PM Stephen Gallagher  wrote:
>
> On Fri, Dec 6, 2019 at 1:52 PM Alexander Ploumistos
>  wrote:
> >
> > On Fri, Dec 6, 2019 at 6:14 PM Miro Hrončok  wrote:
> > >
> > > Rollback or disable explicitly.
> >
> > I had been busy testing a bunch of other packages from koji and
> > rollback is going to break a lot of things at this point.
> > Could you please explain how to install the new protobuf build and get
> > rid of the pulled-in dependencies (in a way that people with
> > overworked and under-functioning brain cells could understand)?
>
> In theory, `dnf module disable eclipse` and `dnf downgrade protobuf`
> should work. I haven't tried this myself.

Thanks Stephen, it turns out that on this system I had only
protobuf-lite installed, but the issue was the same. I disabled ant,
eclipse and maven modules and downgraded protobuf-lite. I need to
remember to check my work PC on Monday, I ran an update just before
leaving and I do have all of the above installed there.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-06 Thread Lennart Poettering

On Fr, 06.12.19 18:58, Lata Lante (latala...@cock.li) wrote:

> > If you use LUKS/dm-crypt without dm-integrity and you have a clue
> > where things are located then you can change files without anything
> > being able to detect that. (On btrfs you might have some luck, since
> > it has data checksumming, but ext4 and other traditional file systems
> > do not).
> Of course Ext4 can.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f60c55a94e1d127186566f06294f2dadd966e9b4

Uh? fs-verity is read-only integrity protection, i.e. akin to
dm-verity, not akin to dm-integrity.

Also fs-verity applies to individual files only, it thus only has very
specific usecases. You cannot sensibly do fs-verity across the whole
OS tree, you'd spent agres to set it up at boot...

Lennart

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

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Stephen Gallagher

On Fri, Dec 6, 2019 at 1:52 PM Alexander Ploumistos
 wrote:
>
> On Fri, Dec 6, 2019 at 6:14 PM Miro Hrončok  wrote:
> >
> > Rollback or disable explicitly.
>
> I had been busy testing a bunch of other packages from koji and
> rollback is going to break a lot of things at this point.
> Could you please explain how to install the new protobuf build and get
> rid of the pulled-in dependencies (in a way that people with
> overworked and under-functioning brain cells could understand)?

In theory, `dnf module disable eclipse` and `dnf downgrade protobuf`
should work. I haven't tried this myself.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-06 Thread Lata Lante

> If you use LUKS/dm-crypt without dm-integrity and you have a clue
> where things are located then you can change files without anything
> being able to detect that. (On btrfs you might have some luck, since
> it has data checksumming, but ext4 and other traditional file systems
> do not).
Of course Ext4 can.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f60c55a94e1d127186566f06294f2dadd966e9b4
The question is when Fedora users will be able to use fs-verity.
Because for the encryption support package (including Adiantum) they can't wait 
for support.
https://github.com/google/fscrypt
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Alexander Ploumistos

On Fri, Dec 6, 2019 at 6:14 PM Miro Hrončok  wrote:
>
> Rollback or disable explicitly.

I had been busy testing a bunch of other packages from koji and
rollback is going to break a lot of things at this point.
Could you please explain how to install the new protobuf build and get
rid of the pulled-in dependencies (in a way that people with
overworked and under-functioning brain cells could understand)?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Allow comments and discussion even though an update was pushed to stable

2019-12-06 Thread Robbie Harwood

"Johannes Lips"  writes:

> What I found weird is that you can't comment on an update, which is
> already pushed to stable. A lot of users are only hit by a bug, once
> it reaches stable and then you don't have any possibility to highlight
> a bug report or an issue with this update. I would like to have the
> possibility to add such an information to an update, which introduced
> the issue.

We already have a tool for reporting issues and problems, and it's not
bodhi.  If there's a problem with an already pushed update, it needs to
be in bugzilla - where it's actually discoverable - not in bodhi, where
it will go nowhere.

>From the other side, as a maintainer, it is important to have as few
channels for reporting issues as possible.  Keeping everything in one
place is important so nothing gets lost, and it all can be queried and
triaged appropriately.

Please do not use bodhi as a bug reporting tool.

Thanks,
--Robbie


signature.asc
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-06 Thread Chris Murphy

On Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr  wrote:
>
> On Thursday, December 5, 2019 8:12:13 PM MST Chris Murphy wrote:
> > Using the word to be defined in the definition is insufficient and
> > vague. It's meaningless.
> >
> > Feature existence is not support. The community members make a thing
> > supported, and it's only by community effort and prioritization that
> > features are supported. The track record of hibernation support, such
> > as it is, is best effort, but not blocking. If it breaks, Fedora ships
> > with it broken. There are flat out not enough resources to treat it
> > with any higher priority than this - it's not a new issue either.
>
> Nonetheless, it is "supported" in Fedora.

And now you're using private terminology, and it amounts to denialism
and arguing rather than issue progression. It's tedious and makes the
conversation as pointless as talking to a wall.

>Several of the major Spins, for
> example, the KDE Spin, even have a big button for it in the Application
> Launcher widget. We don't need for it to be a blocker for it to be supported.
> There are far too many things Fedora can do for each one to be a blocker.

And likewise there are minimum expectations of reliability for
something to be enabled by default, and hibernation does not qualify.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5KQC2SZW42I7ABJGXOZNHQLIBLU5DFO/

>
> > The hibernation image is not signed, thus malicious code could be
> > injected into the image, and loaded and executed upon resume. Contrary
> > to you merely saying things as if that makes them true, there is in
> > fact a security issue with hibernation that is incongruent with the
> > purpose of Secure Boot. It would be no different than allowing
> > arbitrary loading of unsigned kernel modules, which is also disallowed
> > by default on Secure Boot systems.
>
> The purpose of Secure Boot is to limit what boots to vendor keys. We've
> circumvented that, but that doesn't make it a "Secure" system.
>
> It makes very little sense to disallow loading of unsigned kernel modules, or
> resuming from an unsigned swap partition, so long as they're encrypted.
> Whoever implemented this, in my opinion, was misguided.

In the first paragraph you correctly state Secure Boot limits what
boots to code that's been signed by Fedora's signing key (or
alternatively user keys, if so configured). And in the second you
describe a means of thwarting Secure Boot by permitting arbitrary code
execution, and advocate for this by default, while also questioning
the decision making capacity of others.

What does encryption have to do with it? Do you think encryption
mimics or is akin to code signing? Does it provide error detection or
error correction? If you change a single block of encrypted data do
you think upon decryption there's EIO or some kind of warning?

>
> > > What are you suggesting the UX is atrocious for? Modifying the swappiness
> > > value? I have come across situations where a system without swap OOMs,
> > > and
> > > effectively freezes up as a result, causing the user to hard-boot the
> > > system, but I have never seen that with a system where swap was at least
> > > 1x the amount of RAM.
> >
> >
> > The thread I cited contains an example of a consistently reproducible
> > unprivileged compile that acts like a fork bomb that will take down
> > the system, including one with swap size = 1x RAM. It reproduces on
> > baremetal and in a VM. The time to OOM providing some chance of
> > recovery is *extended* the bigger swap is. Thus the problem is
> > actually made worse.
>
> That's not a problem. That's the system doing what you've told it. If you
> don't want it to do that, put quotas on that user. This is what we do in
> enterprise environments, for example.

You're making excuses for an unprivileged process fork bombing a
default installation. And you're also changing the goal post by
blaming the user.

The topic, set by you, is the assertion that you've never seen a
system freeze up when swap size is at least 1x RAM. I have provided a
reproducer that contradicts this. And instead of acknowledging that,
either at face value or testing it yourself, you proceed with totally
off topic distractions that also blame the user.

It's a debate style that is intended to generate more debate without
conclusion or progression of the issues, and I consider it
intellectually dishonest.

> > > It doesn't really make any sense to dismiss this. If it's deemed necessary
> > > for there to be a blocker, we can make a new blocker. That's a
> > > non-issue.
> >
> > You asked who told me that it's not supported, I referenced you the
> > thread discussing that point in detail, and yet you're still being
> > dismissive. You have a hypocrisy problem when you accuse others of
> > being dismissive, and yet being dismissive of others is your default
> > position.
>
> That's because it is supported. It works out of box, and several DEs

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-06 Thread Lennart Poettering

On Fr, 06.12.19 16:42, Marius Schwarz (fedora...@cloud-foo.de) wrote:

> Am 06.12.19 um 08:57 schrieb Lennart Poettering:
> > If you know where stuff is located you can change individual blocks in
> > files. You are not going to know what you are changing them to, but
> > you can change it and traditional files will not detect that you did that.
> >
>
> That is correct, but i did not see, how dm-integrity can help here, as
> there is nothing to compare it to,
> as dm-integrity was invented with raidsystems in mind, where it makes a
> lot of sense.

Nah, one of its primary usecases is to provide authenticated disk
encryption in combination with dm-crypt. See here for example:

https://gitlab.com/cryptsetup/cryptsetup/wikis/DMIntegrity

> I found no evidence that it will autocorrect a "manipulated" sector, and
> i guess, that it does not even know how to fix it.

It will not.

> Does it stop booting?
> Does it send an alarm to the user?
> When does it do this?
> Does it do it at all?
> What if the sector is not hit while booting?
> How and when do we get a notice of the manipulation?

When a sector protected by dm-integrity that has been manipulated is
read dm-integrity will raise EIO to the layer above. If the layer
above is a file system it's up the fs to decide what to do with that
failure.

Lennart

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-06 Thread James Cassell

On Fri, Dec 6, 2019, at 11:40 AM, John M. Harris Jr wrote:
> Are you suggesting "translating", for lack of a better term, the passphrase 
> between all available keyboard layouts? That would decrease the effective 
> security of your system considerably..
> 

I'd suggest "translating" the password between the default layout and all 
layouts selected in anaconda. Just recently, I found that the initramfs honored 
my anaconda key layout, but the rescue initramfs did not. I'd expect that in 
the common case, this would eat one extra luks slot, and could save a lot of 
head ache without meaningfully reducing security.

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

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Tomasz Torcz

On Fri, Dec 06, 2019 at 05:40:23PM +0100, Miro Hrončok wrote:
> On 06. 12. 19 17:36, Miro Hrončok wrote:
> > Today I've attempted to run "dnf upgrade".
> > 
> > It has the following in it:
> > 
> > Upgrading:
> > protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
> > 
> > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
> 
> More to it, the modular protobuf disables Python support in:
> 
> https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27ec852a19b99e7b?branch=eclipse
> 
> My packages explicitly require protobuf for Python support. This is breaking 
> them.

  So this is going to break Ceph, too.

-- 
Tomasz Torcz  “If you try to upissue this patchset I shall be 
seeking
to...@pipebreaker.pl   an IP-routable hand grenade.”  — Andrew Morton (LKML)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

On 06. 12. 19 18:10, Charalampos Stratakis wrote:>> For the record, I've just 
pushed a temporary removal of the eclipse

default stream, so the next compose will not have it. For those of you
who are affected, your best bet would be to use `yum history rollback`
and wait to update again until tomorrow.


I got affected as well and I guess a big number of people also.

Is it safe to assume that with the next compose the extra modules will be 
disabled/removed when doing a dnf update?


As of the moment, once a modular stream is enabled implicilty, there is no way 
to disable it implicitly.



Or do we need to rollback the update?


Rollback or disable explicitly.

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

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Stephen Gallagher

On Fri, Dec 6, 2019 at 12:11 PM Charalampos Stratakis
 wrote:
>
>
>
> - Original Message -
> > From: "Stephen Gallagher" 
> > To: "Development discussions related to Fedora" 
> > 
> > Cc: "Mat Booth" , 
> > protobuf-mainatin...@fedoraproject.org
> > Sent: Friday, December 6, 2019 5:59:50 PM
> > Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for 
> > protobuf
> >
> > On Fri, Dec 6, 2019 at 11:51 AM Igor Gnatenko
> >  wrote:
> > >
> > > Thanks for CCing me (maintainer of protobuf here), I am particularly
> > > not happy that some module (which is not even called protobuf, but
> > > some random Java #$%! with ripped out python support overrides my
> > > builds).
> > >
> > > I have put a proposal into a FESCo ticket.
> > >
> > > On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok  wrote:
> > > >
> > > > Today I've attempted to run "dnf upgrade".
> > > >
> > > > It has the following in it:
> > > >
> > > > Upgrading:
> > > > protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
> > > >
> > > > Enabling module streams:
> > > >   ant
> > > >   eclipse
> > > >   maven
> > > >
> > > >
> > > > I don't consider this behavior adequate for a released Fedora version.
> > > >
> > > > As a maintainer of dependent packages (Cura stack) I have tested and
> > > > built it
> > > > against the nonmodular protobuf. What just happened here and how do I
> > > > track it down?
> > > >
> > > > dnf doesn't even tell me what module is this in. I suppose eclipse.
> > > >
> > > > However, protobuf was not mentioned in 
> > > > https://pagure.io/fesco/issue/2285
> > > >
> >
> >
> > For the record, I've just pushed a temporary removal of the eclipse
> > default stream, so the next compose will not have it. For those of you
> > who are affected, your best bet would be to use `yum history rollback`
> > and wait to update again until tomorrow.
>
> I got affected as well and I guess a big number of people also.
>
> Is it safe to assume that with the next compose the extra modules will be 
> disabled/removed when doing a dnf update? Or do we need to rollback the 
> update?
>

No, the extra modules won't be disabled/removed automatically. The
change I made is to ensure no one else gets hit. You will need to roll
back the update if you were affected.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Charalampos Stratakis



- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Mat Booth" , 
> protobuf-mainatin...@fedoraproject.org
> Sent: Friday, December 6, 2019 5:59:50 PM
> Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for 
> protobuf
> 
> On Fri, Dec 6, 2019 at 11:51 AM Igor Gnatenko
>  wrote:
> >
> > Thanks for CCing me (maintainer of protobuf here), I am particularly
> > not happy that some module (which is not even called protobuf, but
> > some random Java #$%! with ripped out python support overrides my
> > builds).
> >
> > I have put a proposal into a FESCo ticket.
> >
> > On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok  wrote:
> > >
> > > Today I've attempted to run "dnf upgrade".
> > >
> > > It has the following in it:
> > >
> > > Upgrading:
> > > protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
> > >
> > > Enabling module streams:
> > >   ant
> > >   eclipse
> > >   maven
> > >
> > >
> > > I don't consider this behavior adequate for a released Fedora version.
> > >
> > > As a maintainer of dependent packages (Cura stack) I have tested and
> > > built it
> > > against the nonmodular protobuf. What just happened here and how do I
> > > track it down?
> > >
> > > dnf doesn't even tell me what module is this in. I suppose eclipse.
> > >
> > > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
> > >
> 
> 
> For the record, I've just pushed a temporary removal of the eclipse
> default stream, so the next compose will not have it. For those of you
> who are affected, your best bet would be to use `yum history rollback`
> and wait to update again until tomorrow.

I got affected as well and I guess a big number of people also.

Is it safe to assume that with the next compose the extra modules will be 
disabled/removed when doing a dnf update? Or do we need to rollback the update?

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

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-06 Thread Przemek Klosowski via devel

On 12/5/19 6:48 PM, John M. Harris Jr wrote:

c. Resource requirements are excessive, there's no dynamic allocation
so to be safe you need to allocate a minimum of 1x RAM for a swap
partition used for a hibernation image. As a consequence, there's now
an excessive amount of relatively slow swap which can result in swap
thrashing and the effective loss of the system. See "Better
interactivity in low-memory situations "
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffedora-workstation%2Fissue%2F98data=02%7C01%7Cprzemek.klosowski%40nist.gov%7C3d5d788008a44389a37608d779ddc820%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637111865776892532sdata=cBuSZsTyR6EIHF0y45%2B6cLbHiHH%2FgQm0rIdFxSjdGio%3Dreserved=0

What are you talking about? You should have at least 1x RAM for swap whether
you use hibernation or not. If you're having issues, you can adjust the
swappiness as needed. There is no "effective loss of the system" involved.

Many systems have 8, 16 or even 32GB of RAM now. Mine has 16GB, and and
I regularly run out of memory because some Chrome tab is open to a
website that keeps reloading ads and leaking memory, sometimes consuming
gigabytes per tab.

The disk speed being in the double digit MB/s, swapping multiple GB
takes minutes. During this time, the system is unresponsive,
unfortunately---the mouse is frozen, alt-tab does not switch between
apps, etc. Sometimes I can flip to a text console and kill chrome, but
most of the time the only remedy is to wait it out or force reboot. I am
not sure if the freezing is mostly kernel's fault or the display
subsystem's fault.

For that reason, I don't believe that the old advice of swap = 2*RAM is
relevant today. Even 1*RAM is of questionable utility---the main reason
for 1*RAM guideline is the ability to hibernate to swap, in my opinion.
Instead, I'd say that with the RAM prices being what they are, everyone
should try to buy as much RAM as appropriate for their regular use.

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

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Stephen Gallagher

On Fri, Dec 6, 2019 at 11:51 AM Igor Gnatenko
 wrote:
>
> Thanks for CCing me (maintainer of protobuf here), I am particularly
> not happy that some module (which is not even called protobuf, but
> some random Java #$%! with ripped out python support overrides my
> builds).
>
> I have put a proposal into a FESCo ticket.
>
> On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok  wrote:
> >
> > Today I've attempted to run "dnf upgrade".
> >
> > It has the following in it:
> >
> > Upgrading:
> > protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
> >
> > Enabling module streams:
> >   ant
> >   eclipse
> >   maven
> >
> >
> > I don't consider this behavior adequate for a released Fedora version.
> >
> > As a maintainer of dependent packages (Cura stack) I have tested and built 
> > it
> > against the nonmodular protobuf. What just happened here and how do I track 
> > it down?
> >
> > dnf doesn't even tell me what module is this in. I suppose eclipse.
> >
> > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
> >

For the record, I've just pushed a temporary removal of the eclipse
default stream, so the next compose will not have it. For those of you
who are affected, your best bet would be to use `yum history rollback`
and wait to update again until tomorrow.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

On Fri, 2019-12-06 at 08:58 -0800, Adam Williamson wrote:
> On Fri, 2019-12-06 at 17:40 +0100, Miro Hrončok wrote:
> > On 06. 12. 19 17:36, Miro Hrončok wrote:
> > > Today I've attempted to run "dnf upgrade".
> > > 
> > > It has the following in it:
> > > 
> > > Upgrading:
> > > protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
> > > 
> > > Enabling module streams:
> > >   ant
> > >   eclipse
> > >   maven
> > > 
> > > 
> > > I don't consider this behavior adequate for a released Fedora version.
> > > 
> > > As a maintainer of dependent packages (Cura stack) I have tested and 
> > > built it 
> > > against the nonmodular protobuf. What just happened here and how do I 
> > > track it 
> > > down?
> > > 
> > > dnf doesn't even tell me what module is this in. I suppose eclipse.
> > > 
> > > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
> > 
> > More to it, the modular protobuf disables Python support in:
> > 
> > https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27ec852a19b99e7b?branch=eclipse
> > 
> > My packages explicitly require protobuf for Python support. This is 
> > breaking them.
> 
> Probably caused by this:
> 
> https://pagure.io/releng/fedora-module-defaults/c/eced70a03ad4c97987b26655de64debc881c5cf4?branch=f31
> 
> That protobuf build is indeed in the eclipse module:
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1398456 - note
> its tags are all 'module-eclipse-something'.
> 
> Stephen?

Just found Stephen's reply in Pagure :P

https://pagure.io/releng/fedora-module-defaults/pull-request/187
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

On Fri, 2019-12-06 at 08:58 -0800, Adam Williamson wrote:
> On Fri, 2019-12-06 at 17:40 +0100, Miro Hrončok wrote:
> > On 06. 12. 19 17:36, Miro Hrončok wrote:
> > > Today I've attempted to run "dnf upgrade".
> > > 
> > > It has the following in it:
> > > 
> > > Upgrading:
> > > protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
> > > 
> > > Enabling module streams:
> > >   ant
> > >   eclipse
> > >   maven
> > > 
> > > 
> > > I don't consider this behavior adequate for a released Fedora version.
> > > 
> > > As a maintainer of dependent packages (Cura stack) I have tested and 
> > > built it 
> > > against the nonmodular protobuf. What just happened here and how do I 
> > > track it 
> > > down?
> > > 
> > > dnf doesn't even tell me what module is this in. I suppose eclipse.
> > > 
> > > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
> > 
> > More to it, the modular protobuf disables Python support in:
> > 
> > https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27ec852a19b99e7b?branch=eclipse
> > 
> > My packages explicitly require protobuf for Python support. This is 
> > breaking them.
> 
> Probably caused by this:
> 
> https://pagure.io/releng/fedora-module-defaults/c/eced70a03ad4c97987b26655de64debc881c5cf4?branch=f31
> 
> That protobuf build is indeed in the eclipse module:
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1398456 - note
> its tags are all 'module-eclipse-something'.
> 
> Stephen?

Just found Stephen's reply in Pagure :P

https://pagure.io/releng/fedora-module-defaults/pull-request/187
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

On Fri, 2019-12-06 at 17:40 +0100, Miro Hrončok wrote:
> On 06. 12. 19 17:36, Miro Hrončok wrote:
> > Today I've attempted to run "dnf upgrade".
> > 
> > It has the following in it:
> > 
> > Upgrading:
> > protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
> > 
> > Enabling module streams:
> >   ant
> >   eclipse
> >   maven
> > 
> > 
> > I don't consider this behavior adequate for a released Fedora version.
> > 
> > As a maintainer of dependent packages (Cura stack) I have tested and built 
> > it 
> > against the nonmodular protobuf. What just happened here and how do I track 
> > it 
> > down?
> > 
> > dnf doesn't even tell me what module is this in. I suppose eclipse.
> > 
> > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
> 
> More to it, the modular protobuf disables Python support in:
> 
> https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27ec852a19b99e7b?branch=eclipse
> 
> My packages explicitly require protobuf for Python support. This is breaking 
> them.

Probably caused by this:

https://pagure.io/releng/fedora-module-defaults/c/eced70a03ad4c97987b26655de64debc881c5cf4?branch=f31

That protobuf build is indeed in the eclipse module:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1398456 - note
its tags are all 'module-eclipse-something'.

Stephen?
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Allow comments and discussion even though an update was pushed to stable

On Fri, 2019-12-06 at 06:34 +, Johannes Lips wrote:
> Hi all,
> 
> I was recently bit by a bug, which was caused by a mismatch between
> texlive-biblatex and biber. The technical side is not so important,
> only so much that they need each other in a pretty specific version,
> which is not reflected on the rpm level.
> What I found weird is that you can't comment on an update, which is
> already pushed to stable. A lot of users are only hit by a bug, once
> it reaches stable and then you don't have any possibility to
> highlight a bug report or an issue with this update. I would like to
> have the possibility to add such an information to an update, which
> introduced the issue.

Yeah, I noticed this too. I think it's new, and it doesn't make a lot
of sense to me either, it's an arbitrary restriction. I can only assume
it's intended to avoid spam comments on long-dead updates or something,
but there certainly are legit reasons to comment on a pushed update.

This should probably be filed as an issue against upstream Bodhi,
though.

> Also I would like to ask if it is possible for important updates,
> like the texlive one to increase the stable karma. It really depends
> which mirrors you are using and if you are unlucky the updates get
> pushed to stable, before it reaches updates-testing for you and then
> again there's nothing to add, once it's pushed.

This is set by the person who creates the update. It defaults to 3, but
the submitter can set it to any value (well, not less than 2 for a
critpath update I think). Any provenpackager can edit it too.
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1780702] Please support an EPEL 8 branch

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

Richard Shaw  changed:

   What|Removed |Added

 Blocks||1774926




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1774926
[Bug 1774926] Unable to install package
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1780704] Please support an EPEL 8 branch

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

Richard Shaw  changed:

   What|Removed |Added

 Blocks||1774926




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1774926
[Bug 1774926] Unable to install package
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1780704] New: Please support an EPEL 8 branch

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

Bug ID: 1780704
   Summary: Please support an EPEL 8 branch
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Net-FTP-RetrHandle
  Assignee: ppi...@redhat.com
  Reporter: hobbes1...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



This package is a dependency of BackupPC which is used in many thousands of EL
7 installs and some are migrating to EL 8.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Igor Gnatenko

Thanks for CCing me (maintainer of protobuf here), I am particularly
not happy that some module (which is not even called protobuf, but
some random Java #$%! with ripped out python support overrides my
builds).

I have put a proposal into a FESCo ticket.

On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok  wrote:
>
> Today I've attempted to run "dnf upgrade".
>
> It has the following in it:
>
> Upgrading:
> protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
>
> Enabling module streams:
>   ant
>   eclipse
>   maven
>
>
> I don't consider this behavior adequate for a released Fedora version.
>
> As a maintainer of dependent packages (Cura stack) I have tested and built it
> against the nonmodular protobuf. What just happened here and how do I track 
> it down?
>
> dnf doesn't even tell me what module is this in. I suppose eclipse.
>
> However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Martin Kolman

On Fri, 2019-12-06 at 17:36 +0100, Miro Hrončok wrote:
> Today I've attempted to run "dnf upgrade".
> 
> It has the following in it:
> 
> Upgrading:
> protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
> 
> Enabling module streams:
>   ant
>   eclipse
>   maven
I've noticed this during an update as well, pretty weird behavior when
user has not explicitely asked for a module to be installed & information
what has triggered this action is lacking.

> 
> 
> I don't consider this behavior adequate for a released Fedora version.
> 
> As a maintainer of dependent packages (Cura stack) I have tested and built it 
> against the nonmodular protobuf. What just happened here and how do I track 
> it down?
> 
> dnf doesn't even tell me what module is this in. I suppose eclipse.
> 
> However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
> 
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Issue with Fedora GeoIP service

2019-12-06 Thread Tom Hughes


On 06/12/2019 16:41, Martin Kolman wrote:

On Fri, 2019-12-06 at 08:38 -0600, Chris Adams wrote:


I also installed the Fedora 31 GeoIP packages and ran the geoipupdate,
and that DB has the correct info.

>

IIRC the infra team mentioned some issues with the new geoip database
being incompatible with how the service is currently implemented,
resulting in being stuck with an outdated database until this is resolved.


Sounds like it maybe doesn't have support for GeoLite2 and is using the
old MaxMind GeoLite Legacy databases which haven't been updated since
the start of this year.

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1780702] New: Please support an EPEL 8 branch

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

Bug ID: 1780702
   Summary: Please support an EPEL 8 branch
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Net-FTP-AutoReconnect
  Assignee: ppi...@redhat.com
  Reporter: hobbes1...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



This package is a dependency of BackupPC which is used in many thousands of EL
7 installs and some are migrating to EL 8.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Issue with Fedora GeoIP service

2019-12-06 Thread Martin Kolman

On Fri, 2019-12-06 at 08:38 -0600, Chris Adams wrote:
> When installing Fedora 31 on a system, I noticed that anaconda defaulted
> to US/Pacific for the time zone, rather than the correct US/Central.
> I'm on a Google Fiber connection, and when I check Fedora's service at
> https://geoip.fedoraproject.org/city I get the info for their HQ in
> Mountain View.  I'm pretty sure I got my proper location in the past.
> 
> What geoIP service is Fedora using for this?
AFAIK the service is run as part of the Fedora infrastrucuture, due to
its potentially sensitive nature (every manual installation that has
network access will try to reach this API). It is not a third party provided
API.

>   When I check MaxMind's
> site, they give the correct info for both my IPv4 and IPv6 addresses
> (which BTW the Fedora geoIP lookup doesn't have a v6 address so only
> checks v4).
> 
> I also installed the Fedora 31 GeoIP packages and ran the geoipupdate,
> and that DB has the correct info.
IIRC the infra team mentioned some issues with the new geoip database
being incompatible with how the service is currently implemented,
resulting in being stuck with an outdated database until this is resolved.

But I'm sure the people actually running this will know more, so CCing the 
Fedora infra list.

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

On Friday, December 6, 2019 8:27:32 AM MST Marius Schwarz wrote:
> Am 05.12.19 um 23:02 schrieb Chris Murphy:
> > read "LUKS by default"
> > https://pagure.io/fedora-workstation/issue/82
> > 
> > If you read the whole thing, you should come to understand why the
> > initial agreement to implement full disk encryption was suspended, and
> > also that this issue has a history proving it is being taken seriously
> > and deliberately.
> 
> First paragraph:
> 
> "Figure out the scope - presumably workstation only since servers and
> cloud VMs need to boot unattended. But perhaps not desktop VMs?"
> 
> VM's in the masses are  not installed via anaconda.
> One VM is installed via anaconda, and the rest is a clone of the image
> produced by the install and later setup.
> Thats how cloudservers are born ;)

That's how some people do it, but most "cloudservers" are built automatically 
from a kickstart.

> If the vm is paravirtualized ( i.e. Xen ) you can't even enter a
> plymouth password to unlock a drive.

Well, you can. Why wouldn't you be able to?


> Even if the VM would be encrypted and running in QEMU, which would use up
> a lot of cpu power, it's still not safe.

Yeah, shared resources throw security out the window.

> Same as with the partly encryption of homedirs in homed is
> insecure, only encrypting the vm is insecure too, due to the
> mastersystem being able to intercept anything send to the vm. If someome
> tampered the host, the guest encryption is null and void. If the host is
> encrypted, there is no longer a need to encrypt the vm.

Well, VMs are not generally stored on the drive of the host OS, except in one-
offs and on consumer desktops/laptops.

> "Figure out intersection with current work to use the TPM to allow
> booting to GDM without entering the password."
> 
> Means, if someone steals the device, he can boot a system. Even if we
> assume that the systemcode is safe and there is no way to interrupt the
> bootprocess, we are now able to attack the login, which will be much
> easier than the encryption key, which is massive compared to the
> passwords in use.

Yeah, there are a contingent here that believe that it's not necessary to 
ensure the person booting the device is actually authorized to access the 
content of the laptop..

And, because it makes things "easy" for the user, I get the feeling something 
like this will wind up getting implemented. Oh well.

> So, NO: no booting without someone entering something.
> 
> Besides the already spoken out point, that not all users want
> encryption, because it takes into consideration to manage an additional
> passcode,
> the entire discussion here was about "encrypt everything, or nothing,
> because partly does not help at all".
> 
> BTW:
> 
> "catanzaro commented a year ago Also: tablets need an OSK to be able to
> decrypt the disk."
> 
> Add: grub needs an OSK too, or how do you select the matching kernel?

Adding an on-screen keyboard to GRUB would be even more difficult than adding 
it to the initramfs environment. GRUB simply cannot support that. It'd have to 
be rewritten from the ground up to support that sort of thing.

> Skipping the rest of it, the simple solution to the problem discussed
> would be to ask for encryption more prominent, with a tiny bit of
> background for the user.
> 
> Before i forget, there can be multiply passwords for a luks key, so
> there is no need to wipe a disk, just have a good OSK with all installed
> and or system selected languages at hand.

Are you suggesting "translating", for lack of a better term, the passphrase 
between all available keyboard layouts? That would decrease the effective 
security of your system considerably..

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf


On 06. 12. 19 17:36, Miro Hrončok wrote:

Today I've attempted to run "dnf upgrade".

It has the following in it:

Upgrading:
protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular

Enabling module streams:
  ant
  eclipse
  maven


I don't consider this behavior adequate for a released Fedora version.

As a maintainer of dependent packages (Cura stack) I have tested and built it 
against the nonmodular protobuf. What just happened here and how do I track it 
down?


dnf doesn't even tell me what module is this in. I suppose eclipse.

However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285


More to it, the modular protobuf disables Python support in:

https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27ec852a19b99e7b?branch=eclipse

My packages explicitly require protobuf for Python support. This is breaking 
them.

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

Fedora 31: dnf upgrade suddenly enables modular streams for protobuf


Today I've attempted to run "dnf upgrade".

It has the following in it:

Upgrading:
protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular

Enabling module streams:
 ant
 eclipse
 maven


I don't consider this behavior adequate for a released Fedora version.

As a maintainer of dependent packages (Cura stack) I have tested and built it 
against the nonmodular protobuf. What just happened here and how do I track it down?


dnf doesn't even tell me what module is this in. I suppose eclipse.

However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

On Friday, December 6, 2019 8:30:48 AM MST Marius Schwarz wrote:
> It's not an ui issue, it's a keyboardlayout issue. And therefor teh ui
> needs a change, to be able to select the keyboardlayout the password was
> entered with, which can differ from the one used on boot.

Well, that's not actually the case. It's sufficient for the primary keyboard 
layout of the system to be used during initramfs, which can be changed and 
then the initramfs rebuilt.

> But plymouth ui needs to be changed anyway to get a working OSK, or
> tablets and mobiles are not be able to use encryption.

What you're asking for would be incredibly difficult. It could be done, but 
not with Plymouth, and not without increasing the size of initramfs by several 
10s of not 100s of MB. Right now, Plymouth doesn't handle input. Well, it 
does, but not most things. It's actually the underlying vtty that handles 
input of the passphrase.

-- 
John M. Harris, Jr.
Splentity

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

OCaml 4.09.0 rebuild complete in Rawhide (was: Re: OCaml 4.09.0 will be added to Fedora 32 via a side tag)

2019-12-06 Thread Richard W.M. Jones

This is now complete and soon the new packages will be merged into
Fedora Rawhide:

https://bodhi.fedoraproject.org/updates/FEDORA-2019-2e0b2d6395

A few non-critical packages failed to build, and I will look at these
later unless someone gets around to it before me.  The failures are
listed at the end.

Notable changes:

 - Release notes: https://ocaml.org/releases/4.09.0.html

 - ocaml-camlp4 (grammar extensions) has finally been deprecated.  All
   dependent packages were retired already in Fedora 31, and
   ocaml-camlp4 itself will soon be retired.  Use ocaml-camlp5 or PPX
   extension points instead.

 - ocamlopt -p (native profiling with gprof) has been removed
   upstream.  Their argument is that there are better tools (eg perf)
   and they work fine with OCaml code.
   https://github.com/ocaml/ocaml/issues/2314

 - ocaml-x11 (various demo-level APIs for accessing X11 directly) was
   moved out of the OCaml distribution upstream.  While we might
   consider packaging this separately, my advise is to use Gtk etc
   instead.

 - caml_named_value returns a const pointer.  While this is correct,
   it also broke a couple of our packages and will require upstream
   fixes.

 - RISC-V support should be in better shape.

Rich.

ocaml-tplib
https://koji.fedoraproject.org/koji/buildinfo?buildID=1420345
ocaml-p3l
https://koji.fedoraproject.org/koji/buildinfo?buildID=1420339
libguestfs
https://koji.fedoraproject.org/koji/buildinfo?buildID=1420315
ocaml-camlimages
https://koji.fedoraproject.org/koji/buildinfo?buildID=1420324
ocaml-augeas
https://koji.fedoraproject.org/koji/buildinfo?buildID=1420320
why3
https://koji.fedoraproject.org/koji/buildinfo?buildID=1420306

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Am 06.12.19 um 08:57 schrieb Lennart Poettering:
> If you know where stuff is located you can change individual blocks in
> files. You are not going to know what you are changing them to, but
> you can change it and traditional files will not detect that you did that.
>

That is correct, but i did not see, how dm-integrity can help here, as
there is nothing to compare it to,
as dm-integrity was invented with raidsystems in mind, where it makes a
lot of sense.

I found no evidence that it will autocorrect a "manipulated" sector, and
i guess, that it does not even know how to fix it.

Does it stop booting?
Does it send an alarm to the user?
When does it do this?
Does it do it at all?
What if the sector is not hit while booting?
How and when do we get a notice of the manipulation?

Best regards,
Marius

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Am 06.12.19 um 00:53 schrieb John M. Harris Jr:
>
> There is really no UI/UX issue. It just needs to ask for a password for a key 
> to decrypt. That's it. The UI is limited to either:
> 1, without Plymouth: A line in a framebuffer asking you to enter a password
> 2, with Plymouth: A box in the center of your screen that shows circles as 
> you 
> enter keys, expecting you to enter a password for a key.
>

It's not an ui issue, it's a keyboardlayout issue. And therefor teh ui
needs a change, to be able to select the keyboardlayout the password was
entered with, which can differ from the one used on boot.

But plymouth ui needs to be changed anyway to get a working OSK, or
tablets and mobiles are not be able to use encryption.

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Am 05.12.19 um 23:02 schrieb Chris Murphy:
> read "LUKS by default"
> https://pagure.io/fedora-workstation/issue/82
>
> If you read the whole thing, you should come to understand why the
> initial agreement to implement full disk encryption was suspended, and
> also that this issue has a history proving it is being taken seriously
> and deliberately.

First paragraph:

"Figure out the scope - presumably workstation only since servers and
cloud VMs need to boot unattended. But perhaps not desktop VMs?"

VM's in the masses are  not installed via anaconda.
One VM is installed via anaconda, and the rest is a clone of the image
produced by the install and later setup.
Thats how cloudservers are born ;)

If the vm is paravirtualized ( i.e. Xen ) you can't even enter a
plymouth password to unlock a drive. Even if the VM would be encrypted
and running in QEMU, which would use up a lot of cpu power, it's still
not safe. Same as with the partly encryption of homedirs in homed is
insecure, only encrypting the vm is insecure too, due to the
mastersystem being able to intercept anything send to the vm. If someome
tampered the host, the guest encryption is null and void. If the host is
encrypted, there is no longer a need to encrypt the vm.

"Figure out intersection with current work to use the TPM to allow
booting to GDM without entering the password."

Means, if someone steals the device, he can boot a system. Even if we
assume that the systemcode is safe and there is no way to interrupt the
bootprocess, we are now able to attack the login, which will be much
easier than the encryption key, which is massive compared to the
passwords in use.

So, NO: no booting without someone entering something.

Besides the already spoken out point, that not all users want
encryption, because it takes into consideration to manage an additional
passcode,
the entire discussion here was about "encrypt everything, or nothing,
because partly does not help at all".

BTW:

"catanzaro commented a year ago Also: tablets need an OSK to be able to
decrypt the disk."

Add: grub needs an OSK too, or how do you select the matching kernel?

Skipping the rest of it, the simple solution to the problem discussed
would be to ask for encryption more prominent, with a tiny bit of
background for the user.

Before i forget, there can be multiply passwords for a luks key, so
there is no need to wipe a disk, just have a good OSK with all installed
and or system selected languages at hand.


best regards,
Marius


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

[Bug 1761850] perl-Crypt-Rijndael for EL8

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



--- Comment #6 from Xavier Bachelot  ---
Thanks for the build Robert-André. I guess you did the build with
provenpackager privileges, so we still need to get someone active to take care
of this package, thus I will finish the non-responsive maintainer procedure and
request commit rights.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Should we discontinue the Python Classroom Lab?

2019-12-06 Thread Daniel Walsh

On 12/6/19 5:39 AM, Nicolas Mailhot via devel wrote:
> Le jeudi 05 décembre 2019 à 16:42 -0700, John M. Harris Jr a écrit :
>> Why in the world was Docker removed? Docker is the most popular
>> container 
>> technology, so if we must embrace the "container" systems, why not
>> include the most popular in Fedora?
> Because moby (née docker) is a trainwreck on the technical side (sky-
> high bundling of git snapshots, with disagreement on the correct
> snapshot to bundle between various components, that make maintaining
> docker, and pulling it forward, for example for changes cgroup-side, a
> major endeavour).
>
> In other words: classical technical debt accumulations. Lots of
> unhealthy technical compromises, to be first to market, and get adopted
> (that worked fine), and no plan to deal with what happens afterwards
> (long term maintenance, evolution, and support).
>
> Regards,
>
Docker is still available as Moby package.  Docker Inc changed their
requirements on the use of the name Docker.  So we stopped packaging
Docker directly on Fedora.  Moby is the upstream project comprising a
lot of what Docker is and will be.  So we ship that in Fedora.

Simultaneous with this we began working on splitting apart what was
Docker into a series of smaller tools that could run any OCI/Docker
Image in the same way that the Docker Daemon did.  But with different
security goals.

Skopeo - Allows you to copy container images from any container registry
to other types of container storage including other container
registries.  Think of this as scp for container images. Does not require
root on the host to run.

Buildah - Container image builder that allows the user to build
OCI/Docker images and push them to contianer registries.  Does not
require root.  Allows use of Dockerfile as well as simple bash scripting
for creating container images.  Can be run without any privilege inside
of another container.

Podman - Complete replacement of the Docker CLI.  Implements almost all
of the familiar commands from the Docker CLI with the same CLI.  alias
docker=podman, and your commands should work.  Works rootless as well as
root. Does not require a Daemon to be run. Really works well with
Systemd.  Also supports lots of advanced features like Pods.

CRI-O - Container Runtime Interface Daemon for running Kubernetes
workloads.  Dedicated/optimized to Kubernetes.  Does not support any
other orchestrators.

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

On Friday, December 6, 2019 7:50:35 AM MST Marius Schwarz wrote:
> Am 05.12.19 um 21:21 schrieb Andreas Tunek:
> > On Thu, 5 Dec 2019, 02:11 John M. Harris Jr,  > 
> > > wrote:
> > Rebuild initramfs when the system-wide keyboard
> > layout is changed.
> > 
> > I change my keyboard layout several times every hour.
> 
> I had the wrong keyboard layout shipped with my laptop, and had to
> change the system kb layout very frequently per hour when i needed "|" ;)
> 
> @JMH: Sorry, that idea isn't working in the wild.
> 
> best regards,
> Marius

Unless you're rebooting several times per hour as well, that would still work.

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

On Friday, December 6, 2019 6:52:30 AM MST Marius Schwarz wrote:
> If you just go and buy some cheap usb drives from a single seller, you
> can endup with the same serial numbers on several drives and i'm not
> surprised if they also clone any other IDs.

The serial number doesn't actually matter, and the VID/PID is actually 
expected to be the same for the same product. That's how what I was suggesting 
would actually work, you're trusting essentially *that model* and the kernel 
module that Linux maps it to.

It's not foolproof, as BadUSB is pretty common, but it'd be better than 
nothing.

> I think a "we do our best" approach is here really better than doing
> nothing at all.
> 
> if possible, powering down the usb connectors when they are not in use,
> would be a good idea. That still does not protect from destructive
> fake-usb devices, but simply inserting something in an open port, would
> not work anymore.

The viability of that would depend heavily on the hubs in use.

> I know that not all usb io hw supports it, but when, it should be done.

...as you pointed out. :)

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

On Friday, December 6, 2019 1:02:04 AM MST Lennart Poettering wrote:
> On Do, 05.12.19 16:33, John M. Harris Jr (joh...@splentity.com) wrote:
> 
> 
> > > Locking down the OS itself and locking down the user's home are two
> > > different things, because OS integrity should be bound to different
> > > mechanisms than user data encryption. (i.e. OS integrity should be
> > > bound to vendor trust or TPM, while user data should be bound to
> > > user's security credentials).
> >
> >
> >
> > I could not disagree more. That would be fine if the trust were the user
> > or the organization that owns the machine, but not vendor trust or
> > anything of the like. It's not some third party's system, it's the user
> > or organization's. Additionally, it's much easier to get a third party to
> > sign something for you than to get the users themselves, or an
> > organization, to sign it.
> 
> Humm, so you turn off gpg verification of RPMs you install? Nah, you
> don't, because you put trust in Fedora that the RPMs they build are
> somewhat safe to use. That's what vendor trust means. Since regular
> users (and even very technical ones) cannot personally validate the
> trustworthiness of compiled code we outsource that to distributions,
> and trust the vendor's benevolence and understanding of things. And
> that's the correct way to build integrity for OS resources.

Vendor trust for packages are not the same as vendor trust for the boot 
environment. A better solution for the boot environment, with UX in mind, 
would be to generate a key for the system at install time, and require that 
the kernel+initramfs be signed with that key in order to boot. This would 
prevent individuals, outside of the folks the user has trusted to maintain 
their kernel image for them, normally the packagers of Fedora's kernel but 
sometimes Linux-libre or similar, from modifying their boot environment.

Even for packages, I don't trust Red Hat's key outright. For example, at 
$WORK, where we deploy RHEL, we resign using our own GPG keys when we bring in 
updates, removing things like PackageKit and flatpak.

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Am 05.12.19 um 21:21 schrieb Andreas Tunek:
> On Thu, 5 Dec 2019, 02:11 John M. Harris Jr,  > wrote:
>
>
> Rebuild initramfs when the system-wide keyboard
> layout is changed.
>
>
> I change my keyboard layout several times every hour.
>

I had the wrong keyboard layout shipped with my laptop, and had to
change the system kb layout very frequently per hour when i needed "|" ;)

@JMH: Sorry, that idea isn't working in the wild.

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

[Bug 1761850] perl-Crypt-Rijndael for EL8

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

Robert-André Mauchin  changed:

   What|Removed |Added

 CC||zebo...@gmail.com



--- Comment #5 from Robert-André Mauchin  ---
Yeah sorry I didn't see your non-responsive maintainers processes beforehand,
but I needed this package also. Buildroot override are up if you need it too.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1761850] perl-Crypt-Rijndael for EL8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2019-f7dedf8596 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f7dedf8596

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

On Thursday, December 5, 2019 8:12:13 PM MST Chris Murphy wrote:
> Using the word to be defined in the definition is insufficient and
> vague. It's meaningless.
> 
> Feature existence is not support. The community members make a thing
> supported, and it's only by community effort and prioritization that
> features are supported. The track record of hibernation support, such
> as it is, is best effort, but not blocking. If it breaks, Fedora ships
> with it broken. There are flat out not enough resources to treat it
> with any higher priority than this - it's not a new issue either.

Nonetheless, it is "supported" in Fedora. Several of the major Spins, for 
example, the KDE Spin, even have a big button for it in the Application 
Launcher widget. We don't need for it to be a blocker for it to be supported. 
There are far too many things Fedora can do for each one to be a blocker.

> The hibernation image is not signed, thus malicious code could be
> injected into the image, and loaded and executed upon resume. Contrary
> to you merely saying things as if that makes them true, there is in
> fact a security issue with hibernation that is incongruent with the
> purpose of Secure Boot. It would be no different than allowing
> arbitrary loading of unsigned kernel modules, which is also disallowed
> by default on Secure Boot systems.

The purpose of Secure Boot is to limit what boots to vendor keys. We've 
circumvented that, but that doesn't make it a "Secure" system.

It makes very little sense to disallow loading of unsigned kernel modules, or 
resuming from an unsigned swap partition, so long as they're encrypted. 
Whoever implemented this, in my opinion, was misguided.

> > What are you suggesting the UX is atrocious for? Modifying the swappiness
> > value? I have come across situations where a system without swap OOMs,
> > and
> > effectively freezes up as a result, causing the user to hard-boot the
> > system, but I have never seen that with a system where swap was at least
> > 1x the amount of RAM.
> 
> 
> The thread I cited contains an example of a consistently reproducible
> unprivileged compile that acts like a fork bomb that will take down
> the system, including one with swap size = 1x RAM. It reproduces on
> baremetal and in a VM. The time to OOM providing some chance of
> recovery is *extended* the bigger swap is. Thus the problem is
> actually made worse.

That's not a problem. That's the system doing what you've told it. If you 
don't want it to do that, put quotas on that user. This is what we do in 
enterprise environments, for example.

> > It doesn't really make any sense to dismiss this. If it's deemed necessary
> > for there to be a blocker, we can make a new blocker. That's a
> > non-issue.
> 
> You asked who told me that it's not supported, I referenced you the
> thread discussing that point in detail, and yet you're still being
> dismissive. You have a hypocrisy problem when you accuse others of
> being dismissive, and yet being dismissive of others is your default
> position.

That's because it is supported. It works out of box, and several DEs even have 
a button for it. I don't know if GNOME does, but the GNOME Spin has always 
been a bit special.

The only time it wouldn't work seems to be in one of those special UEFI + 
Secure Boot cases.


-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Am 06.12.19 um 09:02 schrieb Lennart Poettering:
>
> Humm, so you turn off gpg verification of RPMs you install? Nah, you
> don't, because you put trust in Fedora that the RPMs they build are
> somewhat safe to use. That's what vendor trust means. Since regular

As the vendor supplies the checksums, what is your point?

GPG RPM verification is there to make sure, that the supplychain isn't
tampered, not if the base code matches the src someone posted on github.

As many fedora builds have "rh" patches added to them, a deep user
survey of sourceodes used would reveal major differences with the
original code. To name two prominent: Apache & Firefox.

In the end, yes we trust in Fedora Devs not include backdoors into the
software, but it has absolutely nothing to do, with homed only
encrypting userhomedirs, instead of the entire system. That way, the
integrity of the system can not be guaranteed and therefor it does not
matter much, if or if the homedir is encrypted.

best regards,
Marius


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

Issue with Fedora GeoIP service

2019-12-06 Thread Chris Adams

When installing Fedora 31 on a system, I noticed that anaconda defaulted
to US/Pacific for the time zone, rather than the correct US/Central.
I'm on a Google Fiber connection, and when I check Fedora's service at
https://geoip.fedoraproject.org/city I get the info for their HQ in
Mountain View.  I'm pretty sure I got my proper location in the past.

What geoIP service is Fedora using for this?  When I check MaxMind's
site, they give the correct info for both my IPv4 and IPv6 addresses
(which BTW the Fedora geoIP lookup doesn't have a v6 address so only
checks v4).

I also installed the Fedora 31 GeoIP packages and ran the geoipupdate,
and that DB has the correct info.
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

FESCo election results

2019-12-06 Thread Ben Cotton

Greetings, all!

The elections for FESCo for Fedora 31 have concluded, and the results
are shown below.

FESCo is electing 5 seats this time.
A total of 273 ballots were cast, meaning a candidate
could accumulate up to 2184 votes (273 * 8).

The results for the elections are as follows:

  # votes |  name
- +--
1490  | Miro Hrončok
1350  | Kevin Fenzi
1115  | Zbigniew Jędrzejewski-Szmek
 879  | Fabio Valentini
 877  | David Cantrell
- +--
 868  | Justin Forbes
 813  | Randy Barlow
 534  | Pete Walter


Congratulations to the winning candidates, and thank you all
candidates for running this elections!

For results of other elections, see the Community Blog post:
https://communityblog.fedoraproject.org/?p=8471


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

FESCo election results

2019-12-06 Thread Ben Cotton

Greetings, all!

The elections for FESCo for Fedora 31 have concluded, and the results
are shown below.

FESCo is electing 5 seats this time.
A total of 273 ballots were cast, meaning a candidate
could accumulate up to 2184 votes (273 * 8).

The results for the elections are as follows:

  # votes |  name
- +--
1490  | Miro Hrončok
1350  | Kevin Fenzi
1115  | Zbigniew Jędrzejewski-Szmek
 879  | Fabio Valentini
 877  | David Cantrell
- +--
 868  | Justin Forbes
 813  | Randy Barlow
 534  | Pete Walter


Congratulations to the winning candidates, and thank you all
candidates for running this elections!

For results of other elections, see the Community Blog post:
https://communityblog.fedoraproject.org/?p=8471


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: SSL_DEFAULT_CIPHER_LIST vs PROFILE=DEFAULT vs no set_cipher_list()

2019-12-06 Thread Michael Catanzaro

On Fri, Dec 6, 2019 at 9:04 am, Igor Gnatenko 
 wrote:

So my question would be: Should I patch rust-openssl to use
PROFILE=DEFAULT or I should just remove that call entirely? It is not
very clear to me from the guidelines.


That wouldn't be correct. It needs to use PROFILE=SYSTEM (Fedora system 
policy), not PROFILE=DEFAULT (upstream default policy).


Two options:

* You can simply patch out the call to ctx.set_cipher_list() 
(potentially-upstreamable solution)
* You can change the whole string from 
"DEFAULT:!aNULL:!eNULL:!MD5:!3DES:!DES:!RC4:!IDEA:!SEED:!aDSS:!SRP:!PSK" 
to "SYSTEM" (probably slightly clearer for a downstream patch)



Also since I want to get this
upstream, which option is more portable?


I suspect the only portable option would be to delete the call. I 
suspect you cannot use SYSTEM policy except on Fedora/RHEL; it probably 
doesn't exist elsewhere and won't work. I haven't checked to be certain 
for OpenSSL, but that's definitely the case for GnuTLS and it's likely 
the same. Accordingly, the change is not suitable for upstream unless 
upstream is OK with dropping the manual cipher list, so you'll probably 
need to keep this downstream indefinitely.


I think it would be nice for Fedora crypto policy to be adjusted so as 
to be suitable for upstream applications, so we don't have to patch 
applications forever to comply, but this was a deliberate design choice.


Michael

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Am 06.12.19 um 00:33 schrieb John M. Harris Jr:
>
>> Uh, locking down USB like that doesn't really work. USB has no
>> mechanism for recognizing devices securely, which means any whitelist
>> is pointless because any device can claim to be whatever it wants to
>> be. (And yes, it would be great if we could be a bit more secure
>> there, but it's an orthogonal problem)
> Well, that's not entirely true. For example, while devices could easily give 
> a 
> false VID and PID, even just limiting that would be a useful feature, because 
> it'd limit the USB functionality of the system (only the modules Linux maps 
> those VID/PID combos to would be available).
>

If you just go and buy some cheap usb drives from a single seller, you
can endup with the same serial numbers on several drives and i'm not
surprised if they also clone any other IDs.

I think a "we do our best" approach is here really better than doing
nothing at all.

if possible, powering down the usb connectors when they are not in use,
would be a good idea. That still does not protect from destructive
fake-usb devices, but simply inserting something in an open port, would
not work anymore.

I know that not all usb io hw supports it, but when, it should be done.

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

Am 05.12.19 um 21:40 schrieb Chris Murphy:
>
> Hibernation is out of scope to rely on, let alone make a default, for
> at least the following reasons:
> a. It's not sufficiently well supported upstream for regressions that
> may appear in new kernels, and not supported by the Fedora kernel
> team.

For it not beeing there, it works very well on my Surface ;)

The Surface has sleep issues, due to the unsupported intel hw, but
hibernation works fine.


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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-06 Thread Nico Kadel-Garcia

On Fri, Dec 6, 2019 at 3:02 AM Lennart Poettering  wrote:

> Humm, so you turn off gpg verification of RPMs you install? Nah, you
> don't, because you put trust in Fedora that the RPMs they build are
> somewhat safe to use. That's what vendor trust means. Since regular
> users (and even very technical ones) cannot personally validate the
> trustworthiness of compiled code we outsource that to distributions,
> and trust the vendor's benevolence and understanding of things. And
> that's the correct way to build integrity for OS resources.

We also have the source code, for Fedora, which we can compile and
compare, which has its own trust issues. Vendor trust should not be
automatic nor absolute. GPG keys for RPM are also validation keys, and
provide robust, procedurally integrated checksum. for content that is
often transferred unencrypted and thus is vulnerable to transmission
or local transcription errors. Since most yum configurations publish a
pointer to an offsite public GPG key, they're not that useful for
individually maintained 3rd party repos that people may choose to use.

It's rather different when vendor keys are used to encrypt a user's
*own* data. That's the core issue of Trusted Computing. Even if you
generate your own keys, the vendor normally holds a copy in escrow,
and the vendor has the root keys tied to your personal hardware and
work their way down the keychain. It's part of hte lost key data
recovery system, if systemd is going to enter the game of encrypting
local filesystems robustly. I'd suggest taking a look at the lessons
learned from Trusted Computing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1779910] perl-IO-Compress-2.092 is available