Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Miroslav Suchý]

Dne 30.11.2017 v 09:49 Vít Ondruch napsal(a):
> Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
> 
> 1) single version of .spec file to cover the whole Red Hat ecosystem.

I belong to this camp.

Especially if you are a developer of layered application, which is not part of 
Fedora itself (Spacewalk, Zimbra, ...),
then Rawhide it too much-moving target and those developers only develop for 
EPEL and stable Fedoras and merely a bonus.
No one of those developers actually thinks about Rawhide. There is no capacity 
for that.

> To sum this up, my take on packaging guidelines is that *the guidelines
> should document the most recent practices available in Rawhide and this
> should be documented*.

+1

> Covering all the exceptions necessary for older
> Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable
> and what is worse, they slow down entire development of Fedora.

-1

This guideline is not only used by Fedora developers (though it is the target 
group), but it is also used by developers
who develop their application on top of Fedora.

Those exceptions are usually not big. Epel is mentioned in main guidelines 
twice. Exception for older Fedoras in your
Ruby draft is just three lines plus one snippet. Not big impact for us and on 
the other hand, it helps 3rd party
developers a lot.

Versioned Guidelines will not help too much as 3rd party developers do not 
develop *just* for Fedora 26. Or *just* for
EPEL 6. What they need is the difference between those versions.
I thought about using a tagged version in History tab, but that does not help. 
This is a diff against six months older
version of the same document:
https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelines&type=revision&diff=505164&oldid=490812

Mirek

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

excess automated emails from Fedora

[Daniel Pocock]

Hi,

I've opened a bug report[1] about automatically generated emails from
Fedora Fedmsg and other parts of Fedora infrastructure.

Maybe there are other components of Fedora where bug reports like this
should be opened but that isn't completely clear to me.

I'm sending this email to the community to ask a few things:

- to see if other people have useful information to add to the bug report

- to see if anybody can suggest other components to file bug reports
against, or help do so

- to find out if there is existing policy on this issue, a search of the
wiki didn't reveal anything obvious

- to get any general feedback about how the Fedora community feels about
use of email addresses.

Note that I'm not just writing this to complain about the issue, I've
previously done work on tools to help people build dashboards of their
issues and I've blogged about some of those, including how you can get
Github issues in iCalendar[2], Nagios issues in iCalendar[3], Debian
issues in iCalendar[4].  Bugzilla (used by Fedora, Mozilla and GNOME,
for example) already has native iCalendar support.  Harsh Daftary did
work on aggregating[5] things from these sources in a dashboard as a
GSoC project.  Putting this all together, even using the Mozilla
Calendar/Lightning plugin, you can easily merge issues from many places
and see them in priority[2] order which is far more comfortable than
being bombarded by emails and trying to work out which is most
important, which is already fixed by somebody else, etc.

- can anybody comment on other tools like this that put the developers
in control rather than bombarding our inboxes with things?

- would anybody like to help contribute to things like this in future,
for example, mentoring another GSoC project on the dashboard concept?

Regards,

Daniel



1. https://github.com/fedora-infra/fmn/issues/266
2. https://danielpocock.com/github-issues-as-an-icalendar-feed
3. https://danielpocock.com/get-your-nagios-issues-as-an-icalendar-feed
4.
https://danielpocock.com/debian-maintainer-dashboard-now-provides-icalendar-feeds
5.
https://danielpocock.com/aggregating-tasks-multiple-issue-trackers-gsoc-2015-summary
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Package naming question

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I would like to hear opinion of other packagers about naming. We have
`parallel` utility implemented in Rust which is drop-in replacement for GNU
parallel. I was thinking how to name package and how people would expect it to
be named. So far options are:

* rust-parallel
* parallel-rust
* parallel-rs

I dislike first one because it is not ending up in completion while second and
third are quite good.

Thoughts?
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlolE00ACgkQaVcUvRu8
X0zcDg/+J4jaboaEmySwsgHiSNDfVqazoxrcZDp0abS8wRO9jSxXCPU0K/MpBgtg
W3LnJOkEhr4WjRtwoC4MmvZf99sfBo4q6ATfd2hOg0WeYkwP36Fu9lVZUAEP6V0E
zVNp44UCuxJNU9IxUvop4XVJOTmaF0Be3pGrJ2LRliZkIgJgzVwOk8pkv/eO1iwp
Y5j2VK7Wjs1Z2/tuL6/u02GqZOpD/0NE145awQUp2PFNwIwYeP70UZ5OjoqdLPNO
LAWybGPSuoaLN7xT7F3FFvqUBhU6Ypsnc2trd01DyJ81v8ITxeAxZpyMy/jLsoyU
0RyP5UJyzI/joGNLHDQimmBnBH3SOcVr68Sx2TIMLxmsyCFaGmv+ehZlTkRWocnM
QWc0fKOD5FC9W7NY21NOCADG6tuIjj+n8Ncw27gbZ0gexbq/drcq9J7aaiKZ0USf
HA7iKya6OiuSKI2GAzKGMcBzp3GKkcUl+3NSBOw2bB/fF1NneXJDL4FkQVhvC+Ta
G9Hmz3MC+f/amozta7y+pPAzswf5yzArc1Lcw/HWx3QG3S/DAlR+fnJntf+Rgz6I
KRYyasi+RLUizzxBnlOXsi3PM3ppErHXmCfewyyhNup0T+DQsW3Na9/q6nWea/1+
I2WA3kZEmoYHEZM5d3r4I3vPliz0QXJQjNkpicqCxg+A85CBH44=
=TEXI
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package naming question

[Giovanni]

On Mon, Dec 04, 2017 at 10:20:13AM +0100, Igor Gnatenko wrote:
> * rust-parallel
> * parallel-rust
> * parallel-rs

I vote parallel-rust. It's very clear where it comes from.

This choice is probably an interesting one: it would mark some sort of best
practice for the "replacement of Y in X": x-y.

Do you think we will see a lot of rust replacements for standard
utilities in the future?

-- 
010 Giovanni [dacav] Simoni
001 
111
OpenPGP key: 93FC 2A6A 43A4 AAC2 0D8E 5411 2F99 ABB6 BA14 DF9E


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package naming question

[Adam Samalik]

What about an analogy with 'createrepo'? We have:

* createrepo
* createrepo_c

Using this same analogy:

* parallel_rust
* parallel_rs

On Mon, Dec 4, 2017 at 10:20 AM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello,
>
> I would like to hear opinion of other packagers about naming. We have
> `parallel` utility implemented in Rust which is drop-in replacement for GNU
> parallel. I was thinking how to name package and how people would expect
> it to
> be named. So far options are:
>
> * rust-parallel
> * parallel-rust
> * parallel-rs
>
> I dislike first one because it is not ending up in completion while second
> and
> third are quite good.
>
> Thoughts?
> - --
> - -Igor Gnatenko
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlolE00ACgkQaVcUvRu8
> X0zcDg/+J4jaboaEmySwsgHiSNDfVqazoxrcZDp0abS8wRO9jSxXCPU0K/MpBgtg
> W3LnJOkEhr4WjRtwoC4MmvZf99sfBo4q6ATfd2hOg0WeYkwP36Fu9lVZUAEP6V0E
> zVNp44UCuxJNU9IxUvop4XVJOTmaF0Be3pGrJ2LRliZkIgJgzVwOk8pkv/eO1iwp
> Y5j2VK7Wjs1Z2/tuL6/u02GqZOpD/0NE145awQUp2PFNwIwYeP70UZ5OjoqdLPNO
> LAWybGPSuoaLN7xT7F3FFvqUBhU6Ypsnc2trd01DyJ81v8ITxeAxZpyMy/jLsoyU
> 0RyP5UJyzI/joGNLHDQimmBnBH3SOcVr68Sx2TIMLxmsyCFaGmv+ehZlTkRWocnM
> QWc0fKOD5FC9W7NY21NOCADG6tuIjj+n8Ncw27gbZ0gexbq/drcq9J7aaiKZ0USf
> HA7iKya6OiuSKI2GAzKGMcBzp3GKkcUl+3NSBOw2bB/fF1NneXJDL4FkQVhvC+Ta
> G9Hmz3MC+f/amozta7y+pPAzswf5yzArc1Lcw/HWx3QG3S/DAlR+fnJntf+Rgz6I
> KRYyasi+RLUizzxBnlOXsi3PM3ppErHXmCfewyyhNup0T+DQsW3Na9/q6nWea/1+
> I2WA3kZEmoYHEZM5d3r4I3vPliz0QXJQjNkpicqCxg+A85CBH44=
> =TEXI
> -END PGP SIGNATURE-
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 

Adam Šamalík
---
Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

REMINDER: Autumn Elections 2017: Nomination & Campaign period ends today @ 23:59:59 UTC

[Jan Kurik]

Currently we have Nomination & Campaign period [1] in progress and we
still accept nominations to "steering bodies" of the following teams:

* FESCo (Engineering) (5 seats) [2]
* Fedora Council (2 seats) [3]
* Mindshare (2 seats) [4]

This period ends today on 2017-Dec-04 at 23:59:59 UTC.

The full schedule of the Autumn Elections 2017 is available on the
Elections wiki page [1] and on the detailed schedule for F27 [5].

[1] https://fedoraproject.org/wiki/Elections
[2] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[3] https://fedoraproject.org/wiki/Council/Nominations
[4] https://fedoraproject.org/wiki/Mindshare/Nominations
[5] https://fedorapeople.org/groups/schedule/f-27/f-27-elections.html

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package naming question

[Ralf Corsepius]

On 12/04/2017 10:33 AM, Giovanni wrote:

On Mon, Dec 04, 2017 at 10:20:13AM +0100, Igor Gnatenko wrote:

* rust-parallel
* parallel-rust
* parallel-rs


I vote parallel-rust. It's very clear where it comes from.

This choice is probably an interesting one: it would mark some sort of best
practice for the "replacement of Y in X": x-y.


We already have such practices in place.


Do you think we will see a lot of rust replacements for standard
utilities in the future?


Before such effort can take effect, replacing a well established package 
with another one will have to prove its viablity and sustainabilty.


ATM, to me personally, replacing packages with rust package qualifies as 
non-sense, probably based on personal preferences and religion.



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

Re: Package naming question

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2017-12-04 at 10:50 +0100, Adam Samalik wrote:
> What about an analogy with 'createrepo'? We have:
> 
> * createrepo
> * createrepo_c

That's only because createrepo_c is upstream name.

> Using this same analogy:
> 
> * parallel_rust
> * parallel_rs

This is really worst user experience.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlolHQEACgkQaVcUvRu8
X0yaJQ/+L9WLnv2YtiRmndKs5x08R5pBb9wE6rqMCVKcdig7zvQindrJctBv7+aO
DfpqGCCsYk54uVsv3vhoHWHoA4IwYm/AvkAyI52b9/wo0AxXvZikS0VwbqPNUuAP
5thG/ojTCJF7fpYHQzaoI5SIIPLyHPFksKWsYfsp08tnZ2Y8OpJeBDDE+prP0I73
+zLD376JpfqYm7JEVUuZqIWNRrks8PlJqxzVA0yc+Py0h5eixA+ehWUDwZrvoHV6
Vbf8taUKVwOBtH7WlWS+Eq6GDmk5CKDdEoq3Qvrec6vr8LSFKi2mWN6Jipqry8dc
psokbiJhYG/sBGZgdaZvea4lCHW7isQHKiB4yAT0WvodphNBASfmGkQH6gKyVCL+
eeToRMbFEX0jEj5Y58qJW5alY7MWGJrgLjTaQd8hovHV0e0Xs3M2PLecIqbt2+a3
aZnpDa/YvcaA6zl1D6wED7ugumKdznP5iIeNMJU6gClfV48+Ox/ho4U4ABE9plle
0RAWHoHjppWvbBdhWINq1w16RI2+HqCCKcnBV9mW3znr01/9F0H7OZ3Wi99YKYs6
EiftkxYrGE1xRXyTSbk8L4EXiTDZxglBtWJXGUhLekAx9wMlYYb9Vh6cx8GJOyVU
bcvQfhLzdlh85hKiXM4hRXnKaqtdfpZ4e7U6pM5SK574WP+Osoc=
=zzi0
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package naming question

[Giovanni]

On Mon, Dec 04, 2017 at 10:56:43AM +0100, Ralf Corsepius wrote:
> We already have such practices in place.

Sorry, I had no idea :) Then probably that 'best practice' one would be a
good name suggestion for this case too.

Btw, where is this information? I skimmed again through the Naming
Guidelines, but I cound find no reference.

> Before such effort can take effect, replacing a well established package
> with another one will have to prove its viablity and sustainabilty.
>
> ATM, to me personally, replacing packages with rust package qualifies as
> non-sense, probably based on personal preferences and religion.

Agreed. As long as there is no evident advantage, with no interface change
whatsoever, it could only break the working things which rely on the
original one! But providing a replacement does not need replacing it by
default. :)

-- 
010 Giovanni [dacav] Simoni
001 
111
OpenPGP key: 93FC 2A6A 43A4 AAC2 0D8E 5411 2F99 ABB6 BA14 DF9E


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self Introduction: Ryan Breaker

[Charalampos Stratakis]

Hello Ryan and welcome!

- Original Message -
> From: "Ryan Breaker" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, December 1, 2017 10:46:27 PM
> Subject: Self Introduction: Ryan Breaker
> 
> 
> 
> Hello everyone, my name is Ryan and I’m looking to join the Packager group to
> revive and update the netatalk package, as well as be available to assist
> with anything else I find myself interested in helping with. I’m a huge fan
> of Fedora and it’s long been my favorite Linux distribution so I’m excited
> to be able to give back in some way.
> 
> 
> 
> The package I’m looking to revive and update already exists on Pagure at
> https://src.fedoraproject.org/rpms/netatalk and it’s just a few minor
> releases behind from its previous commit before being marked as dead so once
> able I will do just that.
> 
> 
> 
> Feel free to let me know if there’s anything else I need to do to get the
> access I need; I already forked it but don’t appear to be able to pull or
> push to it yet.
> 
> 
> 
> Thanks,
> 
> Ryan Breaker
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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

Proven packagers - stop messing with other people packages!!

[David Kaspar [Dee'Kej]]

Hello folks,

I do not want to point any fingers, so I'll be adressing this to all proven
packagers...

Stop messing with other people packages without trying to contact them via
e-mail/IRC, or openind new BZ!
Especially when you see they are actively maintaining the package and your
changes are not critical for Fedora to function/boot.
THIS IS NOT OKAY, AND YOU ARE ABUSING THE RIGHTS YOU WERE GIVEN!

Fedora proven packagers policy (
https://fedoraproject.org/wiki/Provenpackager_policy) explicitly says:
"Provenpackagers should try to communicate with owners of a package in
bugzilla, irc or email prior to making changes. They should be careful not
to change other people's packages needlessly and try to do the minimal
changes required to fix problems, ..."

Last note to proven packagers: You're not BDFLs - so start acting according
to it. Thank you!

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Different default users for Web Server httpd, nginx and php-fpm

[Remi Collet]

> My situation before was:
> /var/www/html -> owned by apache:apache

BAD, apache don't need to own this directory, only to read it
Very common way to decrease security.

(perhaps it may need to be able to write in some sub-directory, e.g.
upload, temp, cache, ...)


> httpd -> running as apache:apache
> php-fpm -> running as apache:apache

So default configuration

> Switching to nginx, I had to :
> /var/www/html  -> chown nginx:nginx
> php-fpm running -> as nginx:nginx

Why do you think to have to change php-fpm user ?
It run using apache account by default,
especially for packaged web-app which rely on this.

nginx only need to be able to read (for static assets)
and the fpm socket have needed permissions for nginx

In fedora, 3 configurations are designed works out of the box

httpd + mod_php (default in Fedora < 27)
httpd + php_fpm (default since Fedora 27)
nginx + php-fpm

Some packaged applications also works using these 3 default configurations.


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

Re: Proven packagers - stop messing with other people packages!!

[Josh Boyer]

On Mon, Dec 4, 2017 at 7:33 AM, David Kaspar [Dee'Kej]
 wrote:
> Hello folks,
>
> I do not want to point any fingers, so I'll be adressing this to all proven
> packagers...
>
> Stop messing with other people packages without trying to contact them via
> e-mail/IRC, or openind new BZ!
> Especially when you see they are actively maintaining the package and your
> changes are not critical for Fedora to function/boot.
> THIS IS NOT OKAY, AND YOU ARE ABUSING THE RIGHTS YOU WERE GIVEN!
>
> Fedora proven packagers policy
> (https://fedoraproject.org/wiki/Provenpackager_policy) explicitly says:
> "Provenpackagers should try to communicate with owners of a package in
> bugzilla, irc or email prior to making changes. They should be careful not
> to change other people's packages needlessly and try to do the minimal
> changes required to fix problems, ..."
>
> Last note to proven packagers: You're not BDFLs - so start acting according
> to it. Thank you!

While I'm sure this is well intentioned, it's not actually going to
solve anything.  You're shouting at an entire group of people, 99% of
whom likely have no context for what you're upset about.

Perhaps you could provide some examples of what the actual problems are.

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

Re: Proven packagers - stop messing with other people packages!!

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 04, 2017 at 01:33:09PM +0100, David Kaspar [Dee'Kej] wrote:
> Hello folks,
> 
> I do not want to point any fingers, so I'll be adressing this to all proven
> packagers...
> 
> Stop messing with other people packages without trying to contact them via
> e-mail/IRC, or openind new BZ!
> Especially when you see they are actively maintaining the package and your
> changes are not critical for Fedora to function/boot.
> THIS IS NOT OKAY, AND YOU ARE ABUSING THE RIGHTS YOU WERE GIVEN!
> 
> Fedora proven packagers policy (
> https://fedoraproject.org/wiki/Provenpackager_policy) explicitly says:
> "Provenpackagers should try to communicate with owners of a package in
> bugzilla, irc or email prior to making changes. They should be careful not
> to change other people's packages needlessly and try to do the minimal
> changes required to fix problems, ..."
> 
> Last note to proven packagers: You're not BDFLs - so start acting according
> to it. Thank you!

Hi Dee'Kej,

you must be aware that there are hundreds of proven packagers doing hundreds
of changes on hundreds of packages at various points in time.
If you say neither which packages you have in mind, modified when, by whom,
or for what purpose, you're very unlikely to reach the right people.

I suggest that you list in a _calm_ technical manner some specific commits
which you think shouldn't have been done under pp policy and why.
Please note that aside from the part you quoted there are other rules which
allow fairly significant actions to be taken by pps assuming certain
procedures are followed, so it may all have been according to policy.

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

Re: Proven packagers - stop messing with other people packages!!

[Christian Dersch]

Hi all,

sorry but I think this mail goes into the completely wrong direction… You 
claim that you don't want to point any fingers, but instead you blame *all* 
proven packagers, including me. I claim that I respect the policies for 
example. Only reason to use the rights are pure rebuilds for me, in case of 
soname bumps and already broken dependencies. So when things are already 
broken and a rebuild solves it. For changes in packages I used Bugzilla for 
long time. Now we have pagure with its very nice pull request mechanism I use 
in these cases to work with the maintainer. I know many other (proven) 
packagers doing the same. So blaming all of them… sorry… NO!

I know what you want to say though, as I also know that *some* proven 
packagers abuse their rights. I also had that situation with few of my 
packages, but I managed this with the specific proven packager then. If some 
proven packagers abuses his access again and again, an issue has to be filed 
@FESCo, so they can instruct the packager and maybe remove the proven packager 
rights later in case of another abuse.

Greetings,
Christian


On Monday 4 December 2017 13:33:09 CET David Kaspar [Dee'Kej] wrote:
> Hello folks,
> 
> I do not want to point any fingers, so I'll be adressing this to all proven
> packagers...
> 
> Stop messing with other people packages without trying to contact them via
> e-mail/IRC, or openind new BZ!
> Especially when you see they are actively maintaining the package and your
> changes are not critical for Fedora to function/boot.
> THIS IS NOT OKAY, AND YOU ARE ABUSING THE RIGHTS YOU WERE GIVEN!
> 
> Fedora proven packagers policy (
> https://fedoraproject.org/wiki/Provenpackager_policy) explicitly says:
> "Provenpackagers should try to communicate with owners of a package in
> bugzilla, irc or email prior to making changes. They should be careful not
> to change other people's packages needlessly and try to do the minimal
> changes required to fix problems, ..."
> 
> Last note to proven packagers: You're not BDFLs - so start acting according
> to it. Thank you!
> 
> David Kaspar [Dee'Kej]
> *Associate Software Engineer*
> *Brno, Czech Republic*
> 
> RED HAT | TRIED. TESTED. TRUSTED.
> Every airline in the Fortune 500 relies on Red Hat.
> Find out why at Trusted | Red Hat .

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

F28 System Wide Change: Switch libcurl to use libssh instead of libssh2

[Jan Kurik]

= System Wide Change:Switch libcurl to use libssh instead of libssh2 =
https://fedoraproject.org/wiki/Changes/libssh-in-libcurl

Change owner(s):
* Kamil Dudka 

libcurl currently uses libssh2 to implement the SSH layer of SCP and
SFTP protocols. After implementing this change, libcurl will use the
libssh library instead.


== Detailed Description ==
libcurl currently uses libssh2 to implement the SSH layer of SCP and
SFTP protocols. The libssh2 library uses outdated crypto algorithms
and lacks important features like GSS-API authentication. After
implementing this change, libcurl will use the libssh library instead,
which is now more secure, feature-complete, and with more active
upstream community.


== Scope ==
* Proposal owners:
kdudka (will switch the SSH library in the curl package once it is
supported upstream)

* Other developers:
nmav (currently working on the related pull-request with curl upstream)

* Release engineering:
No action from release engineering is needed for this change (libcurl
ABI is kept), releng review requested at
https://pagure.io/releng/issue/7193

* Policies and guidelines:
unaffected

* Trademark approval:
not needed
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proven packagers - stop messing with other people packages!!

[David Kaspar [Dee'Kej]]

So, to clarify - I'm OK with proven packagers to make changes to package I
(actively) maintain in case I'm unavailable for some longer period of time
(weekend, vacation, etc.), and the changes needed to be done fall into one
of these categories:
 * my package received some high/critical CVE that needs to be patched ASAP
 * my package is causing Fedora not to boot properly/at all
 * my package is causing some serious problems to Fedora infrastructure
(e.g. causing builds to fail, causing Pagure not to work, etc.)
 * my package is causing some other significant problem

When there's no such pressing issue, I would expect the packager to follow
the Fedora policy about proven packagers I mentioned before. To be specific:
 * contact me via IRC first if it is something trivial not worth creating
BZ and I'm available at IRC
 * write me an e-mail if it is something trivial not worth creating BZ and
I'm not available at IRC
 * create a new BZ if it something non-trivial, causing problems to any
users of Fedora

What happened in the case that lead me to write my initial e-mail was this:
1) Proven packager received a BZ report for his own package.
2) Proven packager discovered the issue was actually caused by package I
maintain/own.
3) Instead of switching that BZ to correct component, the proven packager
decided to use his power to fix it himself.
4) He found a fix for it, created a new patch and added it into the package
I maintain/own.

NOTES:
 * The issue itself was not critical at all for Fedora to boot/function, it
was not a CVE and it was not affecting the Fedora infrastructure, nor was
critical at all IMHO.
 * I was available on the IRC during my working hours, but was not
contacted by the proven packager, either via IRC or e-mail.
 * The specfile change was not referencing the BZ it was suppose to fix. It
was containing only a link to upstream commit, where the commit message was
completely irrelevant to the actual BZ.
 * The dist-git commit didn't contain the BZ number or some actually useful
info either.

The reason I'm not mentioning the person's name here is that I'm still
waiting for his reply (or some kind of justification for this approach),
but I really don't think that this actions would (nor should) fall to
"being done according to policy". :) For me, it's more "I don't give a damn
about others"-like approach, which IMHO nobody likes. :)

Because it will be me (or some other maintainer) who will be (and will have
to) deal(ing) with the package in the future, not the proven packager.
Generally this "reckless" approach can cause be a pain for other people
when they will be trying to find out answers to their questions (like "why
was this patch included in the first place?", "can I safely remove it
now?", "how long should it stay in the package?", "could this be the patch
causing some regression I'm facing now?", etc. etc.) And that's one of the
reason why I wrote my initial e-mail to this mailing list - for other
proven packagers to be aware of this and for them to try not to make others
people life harder... :) In the end, we have that saying in Fedora as well
IIRC (when using 'sudo' for the first time): "With great power comes great
responsibility" :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package naming question

[Gerald Henriksen]

On Mon, 04 Dec 2017 10:20:13 +0100, you wrote:

>I would like to hear opinion of other packagers about naming. We have
>`parallel` utility implemented in Rust which is drop-in replacement for GNU
>parallel. I was thinking how to name package and how people would expect it to
>be named. So far options are:
>
>* rust-parallel
>* parallel-rust
>* parallel-rs
>
>I dislike first one because it is not ending up in completion while second and
>third are quite good.

To me the second and third make it look like the package is part of
the existing parallel package - perhaps rust bindings to parallel -
and not an entirely different program.

In other words, I could see people install parallel-rust because "it
must be part of the parallel package" based on its naming and not
realize it is an entirely different program doing the same thing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Switch libcurl to use libssh instead of libssh2

[Michael Cronenworth]

On 12/04/2017 07:47 AM, Jan Kurik wrote:

libcurl currently uses libssh2 to implement the SSH layer of SCP and
SFTP protocols. The libssh2 library uses outdated crypto algorithms
and lacks important features like GSS-API authentication. After
implementing this change, libcurl will use the libssh library instead,
which is now more secure, feature-complete, and with more active
upstream community.


They are both equally active. If you were worried about ECDSA support, guess what? 
Libssh2 now supports it:


https://github.com/libssh2/libssh2/issues/41

I'm not sure this change is really warranted.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package naming question

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 04, 2017 at 09:19:26AM -0500, Gerald Henriksen wrote:
> On Mon, 04 Dec 2017 10:20:13 +0100, you wrote:
> 
> >I would like to hear opinion of other packagers about naming. We have
> >`parallel` utility implemented in Rust which is drop-in replacement for GNU
> >parallel. I was thinking how to name package and how people would expect it 
> >to
> >be named. So far options are:
> >
> >* rust-parallel
> >* parallel-rust
> >* parallel-rs
> >
> >I dislike first one because it is not ending up in completion while second 
> >and
> >third are quite good.
> 
> To me the second and third make it look like the package is part of
> the existing parallel package - perhaps rust bindings to parallel -
> and not an entirely different program.
> 
> In other words, I could see people install parallel-rust because "it
> must be part of the parallel package" based on its naming and not
> realize it is an entirely different program doing the same thing.

Yes. In other words, the problem started when somebody decided to
reimplement a well-known existing package in a different language without
changing the name. It seems like the right solution is to ask the
rust-parallel folks to rename their project instead of squatting on an
existing name.

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

Re: Proven packagers - stop messing with other people packages!!

[David Kaspar [Dee'Kej]]

​Hello Christian,​

On Mon, Dec 4, 2017 at 2:44 PM, Christian Dersch 
wrote:

> Hi all,
>
> sorry but I think this mail goes into the completely wrong direction… You
> claim that you don't want to point any fingers, but instead you blame *all*
> proven packagers, including me.
>

​my intention was not to blame all packagers maintainers, and it definitely
went the wrong direction - I can see that.​


> I claim that I respect the policies for
> example. Only reason to use the rights are pure rebuilds for me, in case of
> soname bumps and already broken dependencies. So when things are already
> broken and a rebuild solves it. For changes in packages I used Bugzilla for
> long time. Now we have pagure with its very nice pull request mechanism I
> use
> in these cases to work with the maintainer. I know many other (proven)
> packagers doing the same.
>

​And for that I thank you - this is what I would expect from proven
packagers workflow.​



> So blaming all of them… sorry… NO!
>

​Please accept my apologies (and others as well) if you're following the
Proven Packager policies and you have taken my initial e-mail personally.
It was not intended to offend people who follow the policies. (Actually it
was not intended to offend anyone.)​


> I know what you want to say though, as I also know that *some* proven
> packagers abuse their rights. I also had that situation with few of my
> packages, but I managed this with the specific proven packager then. If
> some
> proven packagers abuses his access again and again, an issue has to be
> filed
> @FESCo, so they can instruct the packager and maybe remove the proven
> packager
> rights later in case of another abuse.
>

​This was the first time happening for me so I can't tell if it was
actually recurring case or not. It seemed to me too far to take this to
FESco straight away. Instead I tried to remind the proven packagers of the
policy. However, I must admit that the format of this was based on
affection and therefore not ideally chosen.

Best regards,

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

Re: Proven packagers - stop messing with other people packages!!

[Richard Hughes]

On 4 December 2017 at 14:17, David Kaspar [Dee'Kej]  wrote:
> 4) He found a fix for it, created a new patch and added it into the package
> I maintain/own.

Did you say thanks? To any proven packagers out there, feel free to
fix bugs in any of the packages I own.

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

Re: F28 System Wide Change: Switch libcurl to use libssh instead of libssh2

[Kamil Dudka]

On Monday, December 4, 2017 3:31:32 PM CET Michael Cronenworth wrote:
> On 12/04/2017 07:47 AM, Jan Kurik wrote:
> 
> > libcurl currently uses libssh2 to implement the SSH layer of SCP and
> > SFTP protocols. The libssh2 library uses outdated crypto algorithms
> > and lacks important features like GSS-API authentication. After
> > implementing this change, libcurl will use the libssh library instead,
> > which is now more secure, feature-complete, and with more active
> > upstream community.
> 
> 
> They are both equally active.

How are you backing up your statement?

If we count upstream commits in 2017, I see 93 commits in libssh whereas
only 13 commits in libssh2 (including two commits authored by me).

> If you were worried about ECDSA support, guess what?
> Libssh2 now supports it:
> 
> https://github.com/libssh2/libssh2/issues/41

You are not referring to any upstream commit.  The link above points to a 
Github issue, which is open since September 2015 and without any progress 
since September 2017.

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

Re: F28 System Wide Change: Switch libcurl to use libssh instead of libssh2

[Michael Cronenworth]

On 12/04/2017 08:58 AM, Kamil Dudka wrote:

If you were worried about ECDSA support, guess what?
Libssh2 now supports it:

https://github.com/libssh2/libssh2/issues/41

You are not referring to any upstream commit.  The link above points to a
Github issue, which is open since September 2015 and without any progress
since September 2017.


The commit is in the issue, which you will find a PR for it.

https://github.com/libssh2/libssh2/pull/206

The libssh2 upstream may not be as "fast" as the libssh upstream, but there is still 
active involvement from the maintainers on both sides.

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

F28 System Wide Change: Reduce Initial Setup Redundancy

[Jan Kurik]

= System Wide Change: Reduce Initial Setup Redundancy =
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy

Change owner(s):
* Michael Catanzaro 

Currently there is a high level of redundancy between the Anaconda
installer and gnome-initial-setup. This change aims to eliminate these
redundancies and streamline the initial user experience in Fedora
Workstation.



== Detailed Description ==

Firstly, please note that the effects of this change will be
restricted to Fedora Workstation. We do not propose any changes that
affect alternative Fedora installers (e.g. Calamares) or initial setup
tools (e.g. the initial-setup package, not to be confused with
gnome-initial-setup).

A few years ago, Fedora Workstation developers discussed with Anaconda
developers the redundancy between many Anaconda settings and
gnome-initial-setup. The Anaconda developers responded by added a
configuration file mechanism, /etc/sysconfig/anaconda, which can be
used to suppress Anaconda spokes if written before Anaconda runs. This
file is also written by Anaconda to tell the initial-setup tool which
Anaconda spokes the user has visited, so that the initial-setup tool
can suppress specific spokes. Although this functionality has existed
for some time now, the Workstation developers until now failed to
follow up and begin using it. We now intend to make use of this
functionality to suppress Anaconda spokes that are redundant with
gnome-initial-setup. Meanwhile, our friends at Endless OS have added a
similar configuration file for gnome-initial-setup that allows us to
suppress some configuration that is best handled in Anaconda. Below,
we discuss what we plan to do with specific settings.

=== Language and Keyboard Layout ===

Although we do not propose it at this time, language and keyboard
layout selection should be presented to the user *before* entering the
live session, as it is currently too difficult for users to change
these settings unless they are already familiar with Fedora, and --
unless you speak English and use a US keyboard -- these settings must
be changed for the live session to be usable. Both Anaconda and
gnome-initial-setup are too late for configuring these settings. (An
exception would be for netinstalls of Fedora Workstation, where
Anaconda is the best place for this configuration.) In the meantime,
until we have a way to prompt users for these settings earlier than
Anaconda, these panels should be removed from gnome-initial-setup,
because Anaconda is clearly a better place than gnome-initial-setup
for this configuration. (This would affect gnome-initial-setup when
creating the first user account. Additional user accounts created
later would still receive these panels in gnome-initial-setup.)

=== Time and Date ===

We want to remove the time and date spoke from Anaconda, since it is
largely redundant with the timezone page in gnome-initial-setup.
However, it might be necessary to remove this page from
gnome-initial-setup instead, as previously there have been technical
concerns raised regarding the necessity of configuring the system
clock before running the installer. This choice will be based on
technical feedback from the Fedora developer community.

=== Network ===

We will remove the network configuration spoke from Anaconda.
Currently this spoke only allows configuring the system hostname, but
it places restrictions on the possible characters in the hostname that
do not match the restrictions used by Fedora Workstation. Fedora
Workstation uses systemd-hostnamed to allow "pretty" hostnames with
Unicode characters and spaces, which we expect to be displayed
properly and consistently in the user interface, but the Anaconda
configuration does not follow this pattern. Additionally, exposing the
hostname as network configuration is confusing. We may consider adding
a simpler "Computer Name" setting that allows "pretty" characters and
is not presented as a networking setting in the future, but it does
not seem necessary to prompt the user to set a hostname at all.

Note: this applies only to USB install, obviously not to netinstall.
We will need some way to differentiate between the two when writing
the Anaconda configuration file.

=== User Account ===

Currently, users have the option of creating the initial user account
in Anaconda, or not. Anaconda does not require this if the user sets a
root password. Users who do not create a user account in Anaconda are
required to create a user account later, by gnome-initial-setup. This
means we currently have two different ways of creating the first user
account in Workstation, with (potentially) two different sets of bugs.
Since Anaconda allows configuring whether the initial user is added to
the wheel group, it also means some initial users will be in wheel and
others will not. We will remove the user account creation spoke in
Anaconda. All users will create the first user account using
gnome-initial-setup, and all initial users will be added to the 

Fedora Rawhide-20171204.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 86/128 (x86_64), 1/2 (arm)

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

ID: 179114  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/179114
ID: 179115  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/179115
ID: 179117  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/179117
ID: 179118  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/179118
ID: 179120  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/179120
ID: 179124  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/179124
ID: 179125  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/179125
ID: 179136  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/179136
ID: 179138  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/179138
ID: 179139  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/179139
ID: 179140  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/179140
ID: 179141  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/179141
ID: 179151  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/179151
ID: 179152  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/179152
ID: 179154  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/179154
ID: 179157  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/179157
ID: 179159  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/179159
ID: 179168  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/179168
ID: 179170  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/179170
ID: 179172  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/179172
ID: 179173  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/179173
ID: 179175  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/179175
ID: 179176  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/179176
ID: 179177  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/179177
ID: 179178  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/179178
ID: 179179  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/179179
ID: 179180  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/179180
ID: 179181  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/179181
ID: 179182  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/179182
ID: 179183  Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/179183
ID: 179184  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/179184
ID: 179185  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/179185
ID: 179186  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/179186
ID: 179187  Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/179187
ID: 179188  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/179188
ID: 179189  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/179189
ID: 179190  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/179190
ID: 179191  Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/179191
ID: 179192  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/179192
ID: 179193  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/179193
ID: 179194  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/179194
ID: 179195  Test: x86_64

Re: Proven packagers - stop messing with other people packages!!

[David Kaspar [Dee'Kej]]

On Mon, Dec 4, 2017 at 3:54 PM, Richard Hughes  wrote:

> On 4 December 2017 at 14:17, David Kaspar [Dee'Kej] 
> wrote:
> > 4) He found a fix for it, created a new patch and added it into the
> package
> > I maintain/own.
>
> Did you say thanks?


​For what? Creating more work for me? :) If you were self-employed, would
you thank your government for creating more unnecessary work for you? :)
Hmm. I wouldn't think so...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Switch libcurl to use libssh instead of libssh2

[Kamil Dudka]

On Monday, December 4, 2017 4:05:49 PM CET Michael Cronenworth wrote:
> On 12/04/2017 08:58 AM, Kamil Dudka wrote:
> 
> >> If you were worried about ECDSA support, guess what?
> >> Libssh2 now supports it:
> >>
> >>
> >>
> >> https://github.com/libssh2/libssh2/issues/41
> > 
> > You are not referring to any upstream commit.  The link above points to a
> > Github issue, which is open since September 2015 and without any progress
> > since September 2017.
> 
> 
> The commit is in the issue, which you will find a PR for it.
> 
> https://github.com/libssh2/libssh2/pull/206

You are still not referring to an _upstream_ commit.  Someone needs to review 
the pull request and merge it.  Are you volunteering to help with that?

This is an official statement of the upstream maintainer from November 2016:

https://libssh2.org/mail/libssh2-devel-archive-2016-11/0006.shtml

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

Re: Proven packagers - stop messing with other people packages!!

[David Kaspar [Dee'Kej]]

On Mon, Dec 4, 2017 at 4:33 PM, Reindl Harald 
wrote:

>
>
> Am 04.12.2017 um 16:22 schrieb David Kaspar [Dee'Kej]:
>
>> On Mon, Dec 4, 2017 at 3:54 PM, Richard Hughes > > wrote:
>>
>> On 4 December 2017 at 14:17, David Kaspar [Dee'Kej]
>> mailto:dkas...@redhat.com>> wrote:
>> > 4) He found a fix for it, created a new patch and added it into the
>> package
>> > I maintain/own.
>>
>> Did you say thanks?
>> ​For what? Creating more work for me? :) If you were self-employed, would
>> you thank your government for creating more unnecessary work for you? :)
>> Hmm. I wouldn't think so...
>>
> probably nobody told you clear enough that nobody OWNS a fedora package at
> all, if you would follow this list over the years you would know that as i
> do even without beeing a packager
>

​Well, you probably have time to read (almost) every message on
fedora-devel mailing list, but I don't. Nor I have time to discuss
pointless nit-picking on wording (no, I'm not a native speaker and "owning"
a package has most likely a different meaning to me and to you) that
actually don't change a thing in  this discussion. :)

Have a nice day,

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

HackIllinois - Advance Fedora?

[Brian Exelbierd]

I got pinged indirectly by HackIllinois which organizes a
contribution-style hackfest.


http://www.hackillinois.org/
http://www.hackillinois.org/assets/pdf/sponsorship-2018.pdf

Is this something we as Fedora would want to sponsor and send mentors to
to advance Fedora projects?

regards,

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

Re: Proven packagers - stop messing with other people packages!!

[Richard Hughes]

On 4 December 2017 at 15:22, David Kaspar [Dee'Kej]  wrote:
> For what? Creating more work for me? :)

I think maybe it's time to take a step back and reconsider what it is
to be a Fedora "contributor". You don't _own_ anything; we're all
working together as a team.

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

Re: Proven packagers - stop messing with other people packages!!

[Jonathan Wakely]

On 04/12/17 15:17 +0100, David Kaspar [Dee'Kej] wrote:

* The specfile change was not referencing the BZ it was suppose to fix. It
was containing only a link to upstream commit, where the commit message was
completely irrelevant to the actual BZ.
* The dist-git commit didn't contain the BZ number or some actually useful
info either.


These two points are a problem, and make work for other package
mantainers. Fixing a bug without asking your permission is a much
smaller problem IMHO.

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

Re: Proven packagers - stop messing with other people packages!!

[Adam Williamson]

On Mon, 2017-12-04 at 14:54 +, Richard Hughes wrote:
> On 4 December 2017 at 14:17, David Kaspar [Dee'Kej]  
> wrote:
> > 4) He found a fix for it, created a new patch and added it into the package
> > I maintain/own.
> 
> Did you say thanks? To any proven packagers out there, feel free to
> fix bugs in any of the packages I own.

DK has a point about process, though. A patch in a package with no
useful context is one of my least favourite things. As DK says, it's
effectively a "hidden work landmine": whoever put it there has
bequeathed the poor bastard who has to deal with it in future a bunch
of needless work figuring out why the patch is there, where it came
from, and when it can be removed.
-- 
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

hunspell soname bump

[Caolán McNamara]

rawhide hunspell has been bumped to 1.6.2 from 1.5.4, which bumps
libhunspell from 1.4 to 1.5. I believe everything that needs to be
rebuilt has been rebuilt except firefox whose build fails on armv7hl
with an apparently unrelated std::bad_alloc exception during its build
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

License change: cura changed from AGPLv3+ to LGPLv3+

[Miro Hrončok]

https://src.fedoraproject.org/rpms/cura/c/bb8dee5bb6c4e9d92918d96eac353d565c926441?branch=master
--
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 Modular 27 compose report: 20171204.n.1 changes

[Fedora Branched Report]

OLD: Fedora-Modular-27-20171204.n.0
NEW: Fedora-Modular-27-20171204.n.1

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0.00 B
Size of dropped packages:0.00 B
Size of upgraded packages:   0.00 B
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   0.00 B
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: Proven packagers - stop messing with other people packages!!

[David Kaspar [Dee'Kej]]

2 Richard: I think we've hit the cause of misunderstanding here. Many
people around me (including) me use the word "own", because it's shorter
(faster to say/write), even though we mean maintain (in a contributor
sense). It's a slang for us. I don't know anyone around ne who would take
the word "own" literally. The same applies for me.

2 Reindl: And I actually didn't write anything like this - nor I think
anything like this. I thought my follow-up e-mail explained it clearly
enough.

And trying to discuss the meaning of "own" in Fedora package context is
getting us off-topic... So to reiterate - I don't have a problem with
proven packagers fixing something in packages that I maintain. My problem
is when by doing that they create unnecessary more work (and/or some
"hidden work landmine" as nicely stated by Adam), because they do not
follow the Proven Packager Policy, which was IMHO create to also address
exactly this specific issue...

Anyway, I have already apologized to people who follow the Proven Packager
Policy and whom I could offend, and I don't see this dicussion progressing
anywhere. We're starting to beat a dead-horse here...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Modular bikeshed compose report: changes

[Fedora Rawhide Report]

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

Re: REMINDER: Autumn Elections 2017: Nomination & Campaign period ends today @ 23:59:59 UTC

[Dominik 'Rathann' Mierzejewski]

Dear All,
with the Infrastructure Q4 maintenance [1] affecting some critical services
like the Community Blog (giving 503 errors right now) I'd like to ask
to postpone the elections until the services are stable again, i.e.
by one week.

Disclaimer: I'm a FESCo nominee and I'm unable to update my
questionnaire on the Community Blog because of this.

[1] https://status.fedoraproject.org/q4maint.html

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Switch libcurl to use libssh instead of libssh2

[Kevin Kofler]

Kamil Dudka wrote:
> This is an official statement of the upstream maintainer from November
> 2016:
> 
> https://libssh2.org/mail/libssh2-devel-archive-2016-11/0006.shtml

And even by the comparison on libssh2.org:
https://www.libssh2.org/libssh2-vs-libssh.html
libssh is the more powerful library.

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

Re: streamlining fedora-release

[Dennis Gilmore]

El vie, 10-11-2017 a las 09:12 -0500, Neal Gompa escribió:
> On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote:
> > > Zbigniew Jędrzejewski-Szmek wrote:
> > > > The fedora-release package contains stuff that is tied to each
> > > > Fedora
> > > > version and changes slowly, and it also contains the preset
> > > > files for
> > > > systemd units, which change fairly often (a few requests per
> > > > month).
> > > 
> > > Why not have a separate fedora-presets then? Just like fedora-
> > > repos was
> > > split out from fedora-release several releases ago.
> > 
> > Well, pfff, no particular reason, at least from my side. Just
> > opening
> > a new package and going through the (trivial) review, etc., is a
> > bit
> > of up-front effort, and then releasing updates for two packages is
> > always a bit more effort then for one. So instead, I'd want a good
> > reason
> > to make another package and how that is going to solve something.
> > So far I
> > haven't seen anything except some hypothetical issues.
> 
> This would allow us to deduplicate the presets shipped in
> generic-release and fedora-release, wouldn't it?

We do not keep them in sync between fedora-release and generic-release
this is because generic-release is there just to provide an example of
how you would setup a -release package for a custom forked OS. it is
not intended to be a complete drop in for fedora-release.

Dennis


> And as long has it has a "system-presets" Provides, downstream folks
> can swap them easily enough.
> 
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora-Modular 27-20171204.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Docker_base docker x86_64
Server dvd arm

Failed openQA tests: 20/94 (x86_64), 4/19 (i386)

ID: 179287  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/179287
ID: 179293  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/179293
ID: 179307  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/179307
ID: 179311  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/179311
ID: 179313  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/179313
ID: 179314  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/179314
ID: 179335  Test: x86_64 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/179335
ID: 179349  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/179349
ID: 179358  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/179358
ID: 179359  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/179359
ID: 179360  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/179360
ID: 179361  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/179361
ID: 179363  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/179363
ID: 179364  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/179364
ID: 179365  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/179365
ID: 179366  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/179366
ID: 179367  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/179367
ID: 179368  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/179368
ID: 179369  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/179369
ID: 179373  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/179373
ID: 179374  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/179374
ID: 179382  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/179382
ID: 179383  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/179383
ID: 179396  Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/179396

Passed openQA tests: 66/94 (x86_64), 15/19 (i386)

Skipped openQA tests: 2 of 113
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review swaps

[Robert-André Mauchin]

Hello fellow packagers,

I'd like to ask your help for a handful of reviews. The Golang packages were
generated by gofed and the Perl packages by cpanrpm, so they should be fairly
standard and trivial to review.

As before I offer my help in exchange for reviews, anything but PHP and Java.

Best regards,

Robert-André


── 1508126 Review Request: micro - A modern and intuitive terminal-based text 
editor
│  https://bugzilla.redhat.com/show_bug.cgi?id=1508126
│
└── 1508078 Review Request: golang-github-flynn-json5 - Go JSON5 decoder 
package based on encoding/json
 │  https://bugzilla.redhat.com/show_bug.cgi?id=1508078
 │
 ├── 1508060 Review Request: golang-github-kylelemons-godebug - 
Debugging helper utilities for Go
 │   https://bugzilla.redhat.com/show_bug.cgi?id=1508060
 │
 └── 1508075 Review Request: golang-github-robertkrimen-otto - A 
JavaScript interpreter in Golang
  │  https://bugzilla.redhat.com/show_bug.cgi?id=1508075
  │
  └── 1508068 Review Request: golang-gopkg-readline - Pure golang 
implementation for GNU-Readline kind library
   │  https://bugzilla.redhat.com/show_bug.cgi?id=1508068
   │
   └── 1508066 Review Request: golang-github-chzyer-test - 
Golang test utility
   
https://bugzilla.redhat.com/show_bug.cgi?id=1508066



── 1520581 Review Request: perl-Authen-Passphrase - Hashed 
passwords/passphrases as objects
│  https://bugzilla.redhat.com/show_bug.cgi?id=1520581
│
├── 1520568 Review Request: perl-Crypt-MySQL - Emulate MySQL PASSWORD() 
function
│   https://bugzilla.redhat.com/show_bug.cgi?id=1520568
│
├── 1520569 Review Request: perl-Crypt-UnixCrypt_XS - Perl xs interface for 
a portable traditional crypt function
│   https://bugzilla.redhat.com/show_bug.cgi?id=1520569
│
└── 1520572 Review Request: perl-Authen-DecHpwd - DEC VMS password hashing
 │  https://bugzilla.redhat.com/show_bug.cgi?id=1520572
 │
 ├── 1520570 Review Request: perl-Scalar-String - String aspects of 
scalars
 │   https://bugzilla.redhat.com/show_bug.cgi?id=1520570
 │
 └── 1520571 Review Request: perl-Data-Integer - Details of the native 
integer data type
 https://bugzilla.redhat.com/show_bug.cgi?id=1520571

── 1520582 Review Request: perl-Mojolicious-Plugin-I18N - Internationalization 
Plugin for Mojolicious
   https://bugzilla.redhat.com/show_bug.cgi?id=1520582

── 1520584 Review Request: perl-MooseX-Types-NetAddr-IP - NetAddr::IP related 
types and coercions for Moose
   https://bugzilla.redhat.com/show_bug.cgi?id=1520584

── 1520585 Review Request: perl-Test-SQL-Data - Helps running SQL tests: 
database preparing and result matching
   https://bugzilla.redhat.com/show_bug.cgi?id=1520585



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

Re: debug facilities

[Przemek Klosowski]

On 12/01/2017 05:36 PM, Tom Hughes wrote:

On 01/12/17 22:33, Samuel Sieb wrote:

If you do "rpm -qi soundfont-utils" you will find a line like this:
Source RPM  : gt-0.4-23.fc26.src.rpm

That means that this package is a sub-package of gt.  That's where 
you'll find it in bugzilla and the package database. That's also 
probably where the sources are, but I'm not sure about that.  Try 
installing debuginfo for gt and see what happens.

It's a mixture, as you can see in koji:


As I wrote earlier, I did see the connection, but gt-debugsources 
doesn't seem to provide midi-disasm (rpm -ql gt-debugsource  | xargs 
grep -i midi-disasm returns no hits).


Tom's koji hint was right on: the build log shows that midi-disasm is 
built as 'dim' and renamed, presumably in the spec file, which is of 
course not included in the binary RPM.


BTW, how do you locate the koji buildID for a given package?


The bottom line is that it's pretty tricky to figure this out, which is 
a pity because easy debuggability is one of the important cultural 
features of Fedora and FOSS. It's a regression: GDB used to point to 
integrated .debuginfo packages, which was sufficient. Now, maybe GDB 
should suggest installing the source RPM?


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

Re: F28 System Wide Change: Reduce Initial Setup Redundancy

[Samuel Sieb]

On 12/04/2017 07:09 AM, Jan Kurik wrote:

=== User Account ===

others will not. We will remove the user account creation spoke in
Anaconda. All users will create the first user account using
gnome-initial-setup, and all initial users will be added to the wheel
group. Of course, this can be easily changed after installation if
desired.

=== Root Account ===

group. We will remove the root password creation spoke. All
Workstation installs will have no root password set by default, as in
Ubuntu. Having a root password is not useful for nontechnical users,
and it is confusing to ask users to create multiple passwords. Because


This can be a problem if the graphical interface doesn't work on the 
first boot for some reason.  The user is now left with no way to login 
to fix things.

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

Re: Fedora Modular bikeshed compose report: changes

[Przemek Klosowski]

On 12/02/2017 01:15 PM, Fedora Rawhide Report sent this report, quoted 
in its entirety:

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


Could someone associated with Fedora Modular bikeshed look into 
this---the automated reports come out empty for as many cycles as I can 
remember. Maybe if there aren't any changes, don't send anything?

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

Re: Move /usr/include/cpuidle.h to kernel-tools-libs-devel from kernel-headers

[Laura Abbott]

On 11/21/2017 03:25 PM, Laura Abbott wrote:

While experimenting with some refactoring, I noticed that /usr/include/cpuidle.h
was being picked up by the glob for kernel-headers. This is kind of unusual
because /usr/include/cpufreq.h exists in kernel-tools-libs-devel yet both
come out of install from cpupower tools. This header really belongs in
kernel-tools-libs-devel for consistency and I'd like to move it. I don't
anticipate there being any problems but if anyone can think of an issue for
moving this header from kernel-headers to kernel-tools-libs-devel please
let me know. I don't plan on doing anything about this until next week at the
earliest (Thanksgiving here in the US).

Thanks,
Laura


I've heard no objections so I plan to commit this to rawhide.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1408326] build perl-EV for EPEL7

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-EV-4.15-1.el7 has been submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f7e014081f

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

Orphaning optipng

[Till Maas]

Hi,

I would like to orphan optipng. It is a PNG compression optimizer that I
do not use anymore. Usually it does not make much work but two CVEs were
published recently. I will fix them and then orphan the package unless
someone would like to adopt it. Please state four FAS name if you like
to take it.

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

Re: F28 System Wide Change: Reduce Initial Setup Redundancy

[Chris Murphy]

On Mon, Dec 4, 2017 at 1:55 PM, Samuel Sieb  wrote:
> On 12/04/2017 07:09 AM, Jan Kurik wrote:
>>
>> === User Account ===
>>
>> others will not. We will remove the user account creation spoke in
>> Anaconda. All users will create the first user account using
>> gnome-initial-setup, and all initial users will be added to the wheel
>> group. Of course, this can be easily changed after installation if
>> desired.
>>
>> === Root Account ===
>>
>> group. We will remove the root password creation spoke. All
>> Workstation installs will have no root password set by default, as in
>> Ubuntu. Having a root password is not useful for nontechnical users,
>> and it is confusing to ask users to create multiple passwords. Because
>
>
> This can be a problem if the graphical interface doesn't work on the first
> boot for some reason.  The user is now left with no way to login to fix
> things.

Also, for any kind of early boot troubleshooting even once a user is
created, systemd emergency and rescue targets only accept root user
login. If root user is disabled, it's impossible to do such early boot
troubleshooting. So I think systemd needs a way to accept an admin
user (wheel group) as an alternative login rather than only root.


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

Re: Package naming question

[Jun Aruga]

Perl: perl-foo
Python: python-foo
NodeJs (NPM): nodejs-foo
Ruby: rubygem-foo
R: R-foo
PHP: php-foo
Golang:  golang-foo

The prefix pattern "rust-parallel" looks better.

Jun


On Mon, Dec 4, 2017 at 3:45 PM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Mon, Dec 04, 2017 at 09:19:26AM -0500, Gerald Henriksen wrote:
> > On Mon, 04 Dec 2017 10:20:13 +0100, you wrote:
> >
> > >I would like to hear opinion of other packagers about naming. We have
> > >`parallel` utility implemented in Rust which is drop-in replacement for
> GNU
> > >parallel. I was thinking how to name package and how people would
> expect it to
> > >be named. So far options are:
> > >
> > >* rust-parallel
> > >* parallel-rust
> > >* parallel-rs
> > >
> > >I dislike first one because it is not ending up in completion while
> second and
> > >third are quite good.
> >
> > To me the second and third make it look like the package is part of
> > the existing parallel package - perhaps rust bindings to parallel -
> > and not an entirely different program.
> >
> > In other words, I could see people install parallel-rust because "it
> > must be part of the parallel package" based on its naming and not
> > realize it is an entirely different program doing the same thing.
>
> Yes. In other words, the problem started when somebody decided to
> reimplement a well-known existing package in a different language without
> changing the name. It seems like the right solution is to ask the
> rust-parallel folks to rename their project instead of squatting on an
> existing name.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Jun Aruga jar...@redhat.com
IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech
Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modular bikeshed compose report: changes

[Adam Williamson]

On Mon, 2017-12-04 at 16:01 -0500, Przemek Klosowski wrote:
> On 12/02/2017 01:15 PM, Fedora Rawhide Report sent this report, quoted 
> in its entirety:
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> Could someone associated with Fedora Modular bikeshed look into 
> this---the automated reports come out empty for as many cycles as I can 
> remember. Maybe if there aren't any changes, don't send anything?

It's more likely that this happens because the code that's intended to
produce reports for other composes also fires for Bikeshed composes,
but doesn't know how to analyze modular composes properly. That code is
https://pagure.io/compose-utils/blob/master/f/compose_utils/changelog.py
. The reports for F27 modular composes do work, so I suspect the
'Bikeshed' name is likely related here. (I really, really think this
"Bikeshed" name was a terrible idea - it's bad enough that we treat
'Rawhide' as a version in many circumstances, meaning we have reams of
code all over the place which has to handle "any integer plus the
string 'Rawhide'" somehow, without arbitrarily inventing *new* version
strings and making the problem worse.)
-- 
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

Re: Proven packagers - stop messing with other people packages!!

[Michael Schwendt]

On Mon, 4 Dec 2017 15:17:32 +0100, David Kaspar [Dee'Kej] wrote:

> What happened in the case that lead me to write my initial e-mail was this:
> 1) Proven packager received a BZ report for his own package.
> 2) Proven packager discovered the issue was actually caused by package I
> maintain/own.
> 3) Instead of switching that BZ to correct component, the proven packager
> decided to use his power to fix it himself.
> 4) He found a fix for it, created a new patch and added it into the package
> I maintain/own.

Do I understand you correctly that this has happened only once to one
of your packages? And that already has prompted you to create this thread?

> The reason I'm not mentioning the person's name here is that I'm still
> waiting for his reply (or some kind of justification for this approach),
> but I really don't think that this actions would (nor should) fall to
> "being done according to policy". :) For me, it's more "I don't give a damn
> about others"-like approach, which IMHO nobody likes. :)

Oha! You could/should have waited for a response before complaining so
loudly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Reduce Initial Setup Redundancy

[R P Herrold]

On Mon, 4 Dec 2017, Chris Murphy wrote:

> >> === Root Account ===

>>> group. We will remove the root password creation spoke. 
>>> All Workstation installs will have no root password set by 
>>> default, as in Ubuntu. Having a root password is not 
>>> useful for nontechnical users, and it is confusing to ask 
>>> users to create multiple passwords

If this is a communication problem, why remove a password, 
just remove the spoke? 

Set _some_ DRP password, deterministically to an unguessible 
value, and save that value in a well-named file on the root 
volume

# umask 077
# date +%s > /root-passwd.txt ; ( head -n 1 /root-passwd.txt ; \
lvdisplay | grep -i UUID | rev | awk {'print $1'} | rev | \
sort | head -n 1 ) | md5sum  >> /root-passwd.txt

... and set the root password to the value of the last line of 
/root-passwd.txt


An interested user may:
1. note it for a rainy day

2. change it to taste and rm the file

A disinterested user may ignore it

A person to whom the user takes a 'sick box' can use recovery 
media tool, loop moount a balky drive, and read the file to 
note the credential, and then boot down into a recovery mode 
with the needed credential

> Also, for any kind of early boot troubleshooting even once a user is
> created, systemd emergency and rescue targets only accept root user
> login. If root user is disabled, it's impossible to do such early boot
> troubleshooting. So I think systemd needs a way to accept an admin
> user (wheel group) as an alternative login rather than only root.

I really dislike adding a new 'secret way to crack into a box' 
and the complexity it would add to systemd, and auditting the 
same, a lot more than I dislike leaving a cleartext file with 
a complex password.

And of course this does not come anywhere a secured grub 
bootloader discussion, nor LUKS, and clevis and tang ;)

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

Re: Fedora Modular bikeshed compose report: changes

[Adam Williamson]

On Mon, 2017-12-04 at 13:19 -0800, Adam Williamson wrote:
> On Mon, 2017-12-04 at 16:01 -0500, Przemek Klosowski wrote:
> > On 12/02/2017 01:15 PM, Fedora Rawhide Report sent this report, quoted 
> > in its entirety:
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> > Could someone associated with Fedora Modular bikeshed look into 
> > this---the automated reports come out empty for as many cycles as I can 
> > remember. Maybe if there aren't any changes, don't send anything?
> 
> It's more likely that this happens because the code that's intended to
> produce reports for other composes also fires for Bikeshed composes,
> but doesn't know how to analyze modular composes properly. That code is
> https://pagure.io/compose-utils/blob/master/f/compose_utils/changelog.py
> .

Well, now I refresh my memory, it's a bit more than that. I've just
dived in and debugged this, along with puiterwijk. Long story short,
it's basically because the nightly modular compose script doesn't bail
out when the compose fails, but continues with all the steps it should
only do for successful composes - including sending out this
'changelog' mail. The nightly non-modular compose script, by
comparison, checks the return code from pungi-koji and bails out if
it's non-zero, skipping all the steps that should only happen for a
successful compose.

We'll get that fixed somehow.
-- 
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

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2017-12-05 from 10:00:00 to 11:00:00 US/Eastern
   At https://meet.jit.si/fedora-modularity

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5910/

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

Re: [Fedora-packaging] Re: Package naming question

[Jason L Tibbitts III]

> "JA" == Jun Aruga  writes:

JA> Perl: perl-foo Python: python-foo NodeJs (NPM): nodejs-foo Ruby:
JA> rubygem-foo R: R-foo PHP: php-foo Golang: golang-foo

Those are all for libraries in the given language.

JA> The prefix pattern "rust-parallel" looks better.

This is not a library written in rust.

https://fedoraproject.org/wiki/Packaging:Guidelines#Library_or_Application.3F

If you discount the guidelines for multiple parallel-installable
versions of the same package, we don't really have an established naming
convention for alternate versions of a "thing".  Best I can think of are
things like libart_lgpl (which doesn't and maybe never did have a
non-lgpl version), reentrant versions of libraries like libqhull_r
(which has the least useful package %description I've ever seen), though
those aren't generally packaged separately, or, I don't know,
chromium-libs-media-freeworld (which I know isn't a Fedora package).

Honestly I'd just pretend that what you have really _is_ a different
version of the same package, but instead of being version '3', it's
version 'rust'.  And for that we have
https://fedoraproject.org/wiki/Packaging:Naming#Multiple_packages_with_the_same_base_name
which would suggest "parallel-rust".

For the actual executables, we have a long tradition of prefixing 'k'
for kerberized versions of things, and postfixing version numbers,
sometimes with dashes.  Which really doesn't clarify much of anything.
About all we can say with certainty is that this package can't install
/usr/bin/parallel.

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

Re: Fedora Modular bikeshed compose report: changes

[Adam Williamson]

On Mon, 2017-12-04 at 13:59 -0800, Adam Williamson wrote:
> 
> We'll get that fixed somehow.

https://pagure.io/pungi-fedora/pull-request/483

so, this shouldn't happen any more. :)
-- 
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

Re: [Fedora-packaging] Package naming question

[Björn Persson]

Igor Gnatenko  wrote:
> I would like to hear opinion of other packagers about naming. We have
> `parallel` utility implemented in Rust which is drop-in replacement for GNU
> parallel. I was thinking how to name package and how people would expect it to
> be named. So far options are:
> 
> * rust-parallel
> * parallel-rust
> * parallel-rs

Users of a program – as opposed to a library – don't normally need to
know what language the program is written in, and programs packaged in
Fedora – unlike libraries for some languages – don't normally have the
language in the package name.

Is your package meant to be parallel-installable with the parallel
package? If so, what is the program called, since /usr/bin/parallel is
taken? Or is it meant to conflict with GNU Parallel?

Perhaps both the program and the package should have a name that has
some connection to the purpose of the reimplementation? What would be
the reason why a user would choose the Rust implementation over GNU
Parallel? Is it meant to be faster? Even more parallel? Less buggy?
Something else?

If the only reason is that the user hates Perl and wants to use programs
written in Rust instead, then I guess it makes sense to have "rust" in
the package name.

Björn Persson


pgpnoq3lwYxRL.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Reduce Initial Setup Redundancy

[Chris Murphy]

On Mon, Dec 4, 2017 at 2:36 PM, R P Herrold  wrote:
> On Mon, 4 Dec 2017, Chris Murphy wrote:
>
>> >> === Root Account ===
>
 group. We will remove the root password creation spoke.
 All Workstation installs will have no root password set by
 default, as in Ubuntu. Having a root password is not
 useful for nontechnical users, and it is confusing to ask
 users to create multiple passwords
>
> If this is a communication problem, why remove a password,
> just remove the spoke?
>
> Set _some_ DRP password, deterministically to an unguessible
> value, and save that value in a well-named file on the root
> volume

Sounds like a new secret and non-standard way to lock the root
account. Setting the root user's 2nd field in /etc/shadow to ! is a
well understood way of disabling the account.


>
> # umask 077
> # date +%s > /root-passwd.txt ; ( head -n 1 /root-passwd.txt ; \
> lvdisplay | grep -i UUID | rev | awk {'print $1'} | rev | \
> sort | head -n 1 ) | md5sum  >> /root-passwd.txt
>
> ... and set the root password to the value of the last line of
> /root-passwd.txt

Uhh yeah no way. That's like exposing /etc/shadow there except without
a hashed passphrase.


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

Re: F28 System Wide Change: Reduce Initial Setup Redundancy

[Michael Catanzaro]

On Mon, Dec 4, 2017 at 2:55 PM, Samuel Sieb  wrote:
This can be a problem if the graphical interface doesn't work on the 
first boot for some reason. The user is now left with no way to login 
to fix things.


Since the first account will always be an administrator, you can log in 
to that account and use sudo -i to get a root prompt (after first boot).


If graphical interface is not working for the live session, that's no 
different from before this change.


Michael


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

[Fedocal] Reminder meeting : Voting period starts

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Voting period starts on 2017-12-06 from 00:00:00 to 00:00:00 UTC
   

The meeting will be about:
The Voting period of the currently running Fedora Elections has just started. 
Please vote for your candidates to Council [1], Mindshare[2] and FESCo [3].
You can vote until December 18th, 2017 when the voting ends at 23:59:00 UTC.

To help you to make the right decision we have published Fedora
Magazine article [4] summarizing this elections and pointing to
interviews with nominees we have published on Community Blog. It is
definitely worth a look [4].

[1] https://admin.fedoraproject.org/voting/about/council-december-2017

[2] https://admin.fedoraproject.org/voting/about/mindshare-december-2017

[3] https://admin.fedoraproject.org/voting/about/fesco-december-2017

[4] https://fedoramagazine.org/december-2017-elections/

More information available at:
[https://fedoraproject.org/wiki/Elections](https://fedoraproject.org/wiki/Elections)


Source: https://apps.fedoraproject.org/calendar/meeting/8655/

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

Re: F28 System Wide Change: Reduce Initial Setup Redundancy

[Michael Catanzaro]

On 12/04/2017 03:11 PM, Chris Murphy wrote:

Also, for any kind of early boot troubleshooting even once a user is
created, systemd emergency and rescue targets only accept root user
login. If root user is disabled, it's impossible to do such early boot
troubleshooting. So I think systemd needs a way to accept an admin
user (wheel group) as an alternative login rather than only root.


Yes, good point. This is a longstanding problem. Hopefully making 
disabled root the default behavior for Fedora Workstation might nudge 
the systemd developers into fixing it.


Of course, Ubuntu has managed to survive the past year and a half with 
the same nonfuctional rescue prompt, so I don't think it should block 
this change.


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

Autumn Elections 2017: Voting period for FESCo postponed for 3 days

[Jan Kurik]

For the currently running election cycle (Autumn 2017) to FESCo, we
have open 5 seats. During the Nomination period we have received 6
nominations to FESCo [1].

As the following rules of the FESCo election policy [2] are declaring :

* A minimum number of candidates are necessary in order to hold an
election. This will be the number of open seats + 25%.
* If not enough candidates have signed up by the deadline, the
election may be delayed waiting for more candidates to appear, in
coordination with the schedule for combined Fedora elections. If there
are still not enough candidates, the candidates who are present will
be voted upon (or merely confirmed if there are less candidates than
open seats.)

I requested a guidance from Fedora Council [3] with conclusion to
prolong the Nomination period for 3 days and postpone start of the
Voting period for the same time. As of now the schedule for FESCo
elections is as follows:

Nov 21 - Dec 07: Nomination & Campaign period
Dec 08 - Dec 18: Voting period
Dec 19: Result Announcement

The Voting to FESCo is going to be available in the Voting app [4] on
December 8th.

[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] https://fedoraproject.org/wiki/FESCo_election_policy
[3] https://pagure.io/Fedora-Council/tickets/issue/151
[4] https://admin.fedoraproject.org/voting/about/fesco-autumn-2017

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Autumn Elections 2017: Voting period for Council and Mindshare is open

[Jan Kurik]

The Voting period for Mindshare and Council has just started.

Please follow the links bellow to vote for new members of Mindshare
and Council teams:

Mindshare voting:
https://admin.fedoraproject.org/voting/about/mindshare-autumn-2017
Council voting: https://admin.fedoraproject.org/voting/about/council-autumn-2017

The voting period is open until December 18th, 2017 @ 23:59:59 UTC.

The full schedule of the Autumn Elections 2017 is available on the
Elections wiki page [1] and on the detailed schedule for F27 [2].

[1] https://fedoraproject.org/wiki/Elections
[2] https://fedorapeople.org/groups/schedule/f-27/f-27-elections.html

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Autumn Elections 2017: Interviews with candidates are postponed on December 12th, 2017

[Jan Kurik]

Due to some technical and organizational difficulties we are going to
delay the publishing of interviews to December 12th, 2017. Interviews
with candidates which are ready to be published are going to be
scheduled for December 12th. I am going to work with the remaining
candidates on their interviews to make sure we have these ready by
December 11th COB.

More information is available in Council ticket [1].

[1] https://pagure.io/Fedora-Council/tickets/issue/153

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: excess automated emails from Fedora

[Kevin Fenzi]

On 12/04/2017 01:07 AM, Daniel Pocock wrote:
> 
> Hi,
> 
> I've opened a bug report[1] about automatically generated emails from
> Fedora Fedmsg and other parts of Fedora infrastructure.
> 
> Maybe there are other components of Fedora where bug reports like this
> should be opened but that isn't completely clear to me.
> 
> I'm sending this email to the community to ask a few things:
> 
> - to see if other people have useful information to add to the bug report

I do, and have done so. :)

> - to see if anybody can suggest other components to file bug reports
> against, or help do so

Well, the idea of FMN was to try and put all the notifications in one
place, so likely if there are any other places they should be moved to FMN.
> 
> - to find out if there is existing policy on this issue, a search of the
> wiki didn't reveal anything obvious

Well, the policy is that when you are sponsored into the packager group
you get the default set of packager rules. You can remove them, disable
all notifications, add your own or whatever as you like. I don't think
opting in is a good move here as new packagers likely are the people who
need those notices the most.

I could definitely see the welcome to packager email note this and point
people to where they can adjust things.

> - to get any general feedback about how the Fedora community feels about
> use of email addresses.
> 
> Note that I'm not just writing this to complain about the issue, I've
> previously done work on tools to help people build dashboards of their
> issues and I've blogged about some of those, including how you can get
> Github issues in iCalendar[2], Nagios issues in iCalendar[3], Debian
> issues in iCalendar[4].  Bugzilla (used by Fedora, Mozilla and GNOME,
> for example) already has native iCalendar support.  Harsh Daftary did
> work on aggregating[5] things from these sources in a dashboard as a
> GSoC project.  Putting this all together, even using the Mozilla
> Calendar/Lightning plugin, you can easily merge issues from many places
> and see them in priority[2] order which is far more comfortable than
> being bombarded by emails and trying to work out which is most
> important, which is already fixed by somebody else, etc.

Perhaps you would like to write a FMN backend for this model? :)
(we have email and irc now, but adding a ical one should be definitely
possible I think).

Everyone is different... some people like email, some people like irc,
some people like syncing taskwarrior to their tasks, some people like
nothing and only want to run queries when they have time.

> 
> - can anybody comment on other tools like this that put the developers
> in control rather than bombarding our inboxes with things?

You can control things at https://apps.fedoraproject.org/notifications/

> - would anybody like to help contribute to things like this in future,
> for example, mentoring another GSoC project on the dashboard concept?

I'm no developer, but perhaps someone else would like to. You could ask
on the infrastructure list.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Modular 27 compose report: 20171204.n.1 changes

[Fedora Branched Report]

OLD: Fedora-Modular-27-20171204.n.1
NEW: Fedora-Modular-27-20171204.n.1

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: F28 System Wide Change: Reduce Initial Setup Redundancy

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 04, 2017 at 04:09:25PM +0100, Jan Kurik wrote:
> = System Wide Change: Reduce Initial Setup Redundancy =
> https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
> 
> Change owner(s):
> * Michael Catanzaro 
> 
> Currently there is a high level of redundancy between the Anaconda
> installer and gnome-initial-setup. This change aims to eliminate these
> redundancies and streamline the initial user experience in Fedora
> Workstation.
> 
> 
> 
> == Detailed Description ==
> 
> Firstly, please note that the effects of this change will be
> restricted to Fedora Workstation. We do not propose any changes that
> affect alternative Fedora installers (e.g. Calamares) or initial setup
> tools (e.g. the initial-setup package, not to be confused with
> gnome-initial-setup).

Hi,

apart from some more technical issues that people are raising, I find
this text generally hard to read. Not sure to what extent it's the
early hour or the lack of coffee or the text, so see some suggestions
below:

> A few years ago, Fedora Workstation developers discussed with Anaconda
> developers the redundancy between many Anaconda settings and
> gnome-initial-setup. The Anaconda developers responded by added a
> configuration file mechanism, /etc/sysconfig/anaconda, which can be
> used to suppress Anaconda spokes if written before Anaconda runs. This
> file is also written by Anaconda to tell the initial-setup tool which
> Anaconda spokes the user has visited
Does it mean that just visiting a spoke will cause it to be written
to /etc/sysconfig/anaconda to suppress it in g-i-s?
Or does the user actually have to configure something there?

>, so that the initial-setup tool
> can suppress specific spokes. Although this functionality has existed
> for some time now, the Workstation developers until now failed to
> follow up and begin using it. We now intend to make use of this
> functionality to suppress Anaconda spokes that are redundant with
> gnome-initial-setup.
... and to suppress some spokes in g-i-s, afaiu. So this part should
probably go after the next sentence, so that it's clearer that the
suppression will happen both in anaconda and in g-i-s.

> Meanwhile, our friends at Endless OS have added a
> similar configuration file for gnome-initial-setup that allows us to
> suppress some configuration that is best handled in Anaconda. Below,
> we discuss what we plan to do with specific settings.
> 
> === Language and Keyboard Layout ===
> 
> Although we do not propose it at this time, language and keyboard
> layout selection should be presented to the user *before* entering the
> live session, as it is currently too difficult for users to change
> these settings unless they are already familiar with Fedora, and --
> unless you speak English and use a US keyboard -- these settings must
> be changed for the live session to be usable. Both Anaconda and
> gnome-initial-setup are too late for configuring these settings. (An
> exception would be for netinstalls of Fedora Workstation, where
> Anaconda is the best place for this configuration.)
Since that talks about something that will not happen yet, maybe move
it to some "discussion" section?

Also, please consider reworking the text to have in each section
first a short summary of what the decision is, and then the justification
below. This text is long and it's hard to "scan".

> In the meantime,
> until we have a way to prompt users for these settings earlier than
> Anaconda, these panels should be removed from gnome-initial-setup,
> because Anaconda is clearly a better place than gnome-initial-setup
> for this configuration. (This would affect gnome-initial-setup when
> creating the first user account. Additional user accounts created
> later would still receive these panels in gnome-initial-setup.)
> 
> === Time and Date ===
> 
> We want to remove the time and date spoke from Anaconda, since it is
> largely redundant with the timezone page in gnome-initial-setup.
> However, it might be necessary to remove this page from
> gnome-initial-setup instead, as previously there have been technical
> concerns raised regarding the necessity of configuring the system
> clock before running the installer. This choice will be based on
> technical feedback from the Fedora developer community.
> 
> === Network ===
> 
> We will remove the network configuration spoke from Anaconda.
> Currently this spoke only allows configuring the system hostname, but
> it places restrictions on the possible characters in the hostname that
> do not match the restrictions used by Fedora Workstation. Fedora
> Workstation uses systemd-hostnamed to allow "pretty" hostnames with
> Unicode characters and spaces, which we expect to be displayed
> properly and consistently in the user interface, but the Anaconda
> configuration does not follow this pattern. Additionally, exposing the
> hostname as network configuration is confusing. We may consider adding
> a simpler "Computer Name" setting that allows "

Re: F28 System Wide Change: Reduce Initial Setup Redundancy

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 04, 2017 at 06:03:42PM -0600, Michael Catanzaro wrote:
> On 12/04/2017 03:11 PM, Chris Murphy wrote:
> >Also, for any kind of early boot troubleshooting even once a user is
> >created, systemd emergency and rescue targets only accept root user
> >login. If root user is disabled, it's impossible to do such early boot
> >troubleshooting. So I think systemd needs a way to accept an admin
> >user (wheel group) as an alternative login rather than only root.
> 
> Yes, good point. This is a longstanding problem. Hopefully making
> disabled root the default behavior for Fedora Workstation might
> nudge the systemd developers into fixing it.

This has been under discussion for a while [at least 1,2,3].
We currently only allow root to log in emergency or rescue mode,
following what sysvinit systems did traditionally. We simply call
sulogin, and that's the only thing it allows. I'd like to see this
changed to allow either
a) any user to log in, or
b) only users from a specific group like wheel.
Option b) would possibly be more palatable to some people but would
allow additional support in the login programs and/or pam configuration.
So yeah, it's something that should be fixed, but it's not as trivial
as it would seem at first.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211#31
[2] https://github.com/systemd/systemd/issues/7115
[3] https://github.com/systemd/systemd/pull/7116

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

Re: streamlining fedora-release

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 04, 2017 at 12:49:48PM -0600, Dennis Gilmore wrote:
> El vie, 10-11-2017 a las 09:12 -0500, Neal Gompa escribió:
> > On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote:
> > > > Zbigniew Jędrzejewski-Szmek wrote:
> > > > > The fedora-release package contains stuff that is tied to each
> > > > > Fedora
> > > > > version and changes slowly, and it also contains the preset
> > > > > files for
> > > > > systemd units, which change fairly often (a few requests per
> > > > > month).
> > > > 
> > > > Why not have a separate fedora-presets then? Just like fedora-
> > > > repos was
> > > > split out from fedora-release several releases ago.
> > > 
> > > Well, pfff, no particular reason, at least from my side. Just
> > > opening
> > > a new package and going through the (trivial) review, etc., is a
> > > bit
> > > of up-front effort, and then releasing updates for two packages is
> > > always a bit more effort then for one. So instead, I'd want a good
> > > reason
> > > to make another package and how that is going to solve something.
> > > So far I
> > > haven't seen anything except some hypothetical issues.
> > 
> > This would allow us to deduplicate the presets shipped in
> > generic-release and fedora-release, wouldn't it?
> 
> We do not keep them in sync between fedora-release and generic-release
> this is because generic-release is there just to provide an example of
> how you would setup a -release package for a custom forked OS. it is
> not intended to be a complete drop in for fedora-release.

It might be still worth doing, just to avoid the duplication.

Anyway, any thoughts on the major parts of my proposal?

Zbyszek

> > And as long has it has a "system-presets" Provides, downstream folks
> > can swap them easily enough.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org