Re: [ELN] Rebuild ordering and side-tag support

[Till Maas]

Hi,

On Mon, Jun 28, 2021 at 11:55:21AM -0400, Stephen Gallagher wrote:
> Summary: I think we can fix the ELN side-tag rebuild problems and make
> the composes more reliable if we change the mechanism for kicking off
> rebuilds. I'm soliciting feedback to help identify potential issues
> with this proposed approach.

did you consider mirroring the rawhide side-tag for eln directly from
the beginning, so that a build for the rawhide side-tag triggers a
rebuild for the eln side-tag and then the eln side-tag can be merged at
a similar time as the rawhide side-tag. This way the build order would
be the same (except if there are wait-repo delays that are not visible
for the eln automation) and the build load would be distributed.

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

Re: Request for contributions: Demos of Features or other videos for virtual FOSDEM 2021 booth

[Till Maas]

Hi Michel,

On Thu, Jan 21, 2021 at 09:55:04PM -0800, Michel Alexandre Salim wrote:

> [snip]
> > If you would create a video to show at FOSDEM or have one in mind,
> > please add them to the table at
> > https://fedoraproject.org/wiki/FOSDEM_2021#Videos
> > 
> > FOSDEM will be 6-7 February, so if you would like to contribute, it
> > would need to be soon.
> > 
> > There is also a mindshare ticket to track efforts for FOSDEM:
> > https://pagure.io/mindshare/issue/248
> > 
> Do we have a place to track FOSDEM talks that mention Fedora in some
> ways? e.g. I have a talk that will be hosted by their Config Management
> Camp.

Great. I added a section to the wiki page to collect this:

https://fedoraproject.org/wiki/FOSDEM_2021#Presentations_and_other_Events_involving_Fedora

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

Request for contributions: Demos of Features or other videos for virtual FOSDEM 2021 booth

[Till Maas]

Hi,

there will be a virtual booth at FOSDEM 2021 and this allows to show
some videos. This allows to present the latest features in Fedora or
other interesting items. I skimmed over the Features for 33 and 34 and
the following topics seemed to be good for a video:

- IoT edition
- i3 spin
- overview of benefits from btrfs as root filesystem
- ELN
- swap of zram
- sqlite rpmdb
- systemd-resolved
- nano as editor
- network time security
- thermal management
- storage instatiation daemon
- reserve resources for active users
- DNS over TLS
- module obsoletes and EOL
- restart services at end of rpm transaction
- rust crate packages
- update-alternatives for cc and c++
- wayland for KDE
- xwayland as standalone package
- gitrepos master to main
- compress kernel firmware
- maybe something for language updates or package updates that explain
  the new benefits (don't want to list all of them)
- ntp replacement

If you would create a video to show at FOSDEM or have one in mind,
please add them to the table at
https://fedoraproject.org/wiki/FOSDEM_2021#Videos

FOSDEM will be 6-7 February, so if you would like to contribute, it
would need to be soon.

There is also a mindshare ticket to track efforts for FOSDEM:
https://pagure.io/mindshare/issue/248

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

Re: How to easily automate test builds in a COPR project

[Till Maas]

Hi,

On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote:

> 4. Build the packages in COPR.
> 
> Easy enough using a bash script but is there a better way?

packit allows to create test builds in COPR based on GitHub PRs and
probably also releases. Maybe this can make it easier for you, too:
https://packit.dev/

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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Till Maas]

Hi,

On Sat, Dec 12, 2020 at 12:41:44PM -0800, Kevin Fenzi wrote:
> On Fri, Dec 11, 2020 at 12:03:17PM +0100, Till Maas wrote:
> > Hi,
> > 
> > On Fri, Dec 04, 2020 at 11:13:19AM -0800, Kevin Fenzi wrote:
> > 
> > > I don't think you can make branches completely descripive by themselves,
> > > unless possibly you make them really long. 
> > > 
> > > flatpak_branch_where_stable_flatpaks_are_made_from
> > 
> > That it is about flatpaks is already described in the namespace, that it
> > is a branch is clear from git. This only leaves "stable" as the one
> > information in the long name that would be missing.
> 
> Sure, but 'stable' doesn't convey: These are flatpacks built against the
> platform we deem as stable and distributed to all the stable fedora
> releases. :) You just can't contain all the information about a branch
> in it's name. (IMHO).

Yes, it cannot encode everything but it can at least help. Is there any
documentation about the flatpak work in Fedora? The wiki as all the
other information that I find on Google with "flatpak Fedora" only focus
on how to use them, for example https://fedoraproject.org/wiki/Flatpak
I think it is safe to assume that anyone getting involved to this will
at some point learn what is "stable" in the "stable" branch. Then it
will be easier to remember than "main" if "main" means something else in
Fedora RPM packaging.

> > > rawhide_its_the_branch_for_the_development_version_of_fedora_called_rawhide
> > 
> > It is fair to assume that someone who needs to use this already knows
> > what rawhide is. Otherwise they did not have any use for the branch,
> > even if it is called "main", so this long explanation does not make
> > sense, there.
> 
> Well, a new packager may well assume rawhide is main if they are used to
> main being the main development branch... 

Might be. But if they checkout the repo and get a "rawhide" branch, they
should quickly realize that "rawhide" is the branch for "rawhide"
instead of looking for a main branch for rawhide.

> > > I suppose it's ok to make 'rawhide' a symref to main, or 'stable' in the
> > > flatpak case... 
> > 
> > "main" as a symref might help people that are used to using main.
> > Assuming that the symrefs are not visible, it makes more sense to use
> > the descriptive names for the branches such as rawhide/stable. Then they
> 
> Your message seems to have gotten cut off here? :( 
> 
> symrefs appear just like any other ref... so adding one does mean that
> there's now more choices, just 2 of them are exactly the same.

Uh, I guess undo killed this... I mean to also write that then the
"rawhide" branch would also appear as such in the shell prompt.

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

Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)

[Till Maas]

Hi,

this does not seem to be self-contained, since it seems to affect people
outside the SIG (it states that this is also affecting packages that are
not owned by the SIG).

On Wed, Dec 09, 2020 at 01:44:30PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault
> 
> == Summary ==
> 
> For Nodejs, Fedora should only package:
> * The interpreter, development headers/libraries, and the assorted
> tools to manage project-level installations (NPM, yarn, etc.).
> * Packages that provide binaries that users would want to use in their shell.
> * compiled/binary nodejs modules (for now)
> 
> == Owner ==
> 
> * Name: [[User:tdawson| Troy Dawson]]
> * Email: tdaw...@redhat.com
> * Name: [[User:sgallagh| Stephen Gallagher]]
> * Email: sgall...@redhat.com
> * Name: [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html|
> Nodejs SIG]]
> * Email: nod...@lists.fedoraproject.org
> 
> 
> == Detailed Description ==
> 
> The nodejs libraries have been approved to be bundled, and there is
> infrastructure in place for the bundling to work properly.  Currently,

What does this infrastructure look like? How does it help with
addressing security issues in the bundles components effectivly?

> it is recommended that packagers should create individual nodejs
> library packages instead of bundling all of the libraries into the
> package requiring them.

The subject says "Stop Shipping Individual Nodejs Library Packages",
therefore it would be more clear to block all Nodejs libraries in Fedora
instead of only recommending this. Otherwise it will be some half-baked
solution that is probably confusing (Why are some libraries packaged and
others bundled?).

> This change is to make it default to bundle the nodejs libraries with
> the package that needs them, and retire the vast majority of nodejs
> library packages.
> In summary, for Nodejs Fedora should only package:
> * The interpreter, development headers/libraries, and the assorted
> tools to manage project-level installations (NPM, yarn, etc.).
> * Packages that provide binaries that users would want to use in their shell.
> * compiled/binary nodejs modules (for now)

This should also include the tooling that is needed to manage the
bundling.


> == Feedback ==
> 
> There has been a discussion on the fedora nodejs mailing list about
> what to do with the extreme dependency problem of the nodejs library
> packages.  Because of the extreme inter-dependency, upgrading almost
> any package causes others to break.  It has caused most packages to
> rot, remaining on unsupported versions for years.  Many of the nodejs
> packagers are giving up and orphaning their packages, which has caused
> even more problems.
> 
> An initial proposal was to find all of the important nodejs library
> packages and bundle those, making them easier to upgrade and maintain.
> But there was problems with figuring out what was important, and what
> versions should those have.  During that discussion, this rather
> extreme solution of getting rid of all nodejs libraries was proposed.
> To our surprise, it has been the best received suggestion and fixes
> the most problems.

What problems remain?

> 
> == Benefit to Fedora ==
> 
> * In Fedora 33, there are many nodejs libraries that are
> uninstallable, thus causing other programs based off them to also be
> uninstallable.  This gets rid of that problem.
> * Packages in Fedora that use nodejs libraries will be able to use the
> library versions that upstream has tested and approved.
> * If a package in Fedora uses a nodejs library, the packager will not
> have to also package extra individual nodejs library packages.  There
> have been times this has led to over 100 extra packages, each with
> their own package reviews and maintenance problems.  This change will
> lower the workload on that packager, and possibly get more packages
> into Fedora.
> * The nodejs maintainers can concentrate on nodejs itself, instead of
> the whole nodejs library infrastructure.
> * Nodejs developers using Fedora will no longer have to worry about
> Fedora's global nodejs libraries causing conflicts or inconsistencies.
> 
> == Scope ==
> * Proposal owners:
> We will go through the Fedora release and determine what nodejs
> packages Fedora should package. We will implement nodejs library
> bundling on those we already own.  For those that we do not own, we
> will work with their owners to implement nodejs library bundling.

What about future packagers? How will they learn/be enabled to do it the
right way?

> As packages implement nodejs library bundling, we will monitor the
> nodejs libraries and note which ones are no longer required.  When
> they are no longer required, we will retire them, if we own them.  If
> we do not own them, we will work with the owners to retire them, if
> they wish.
> 
> * Other developers:
> For Fedora packagers whose package rely on nodejs libraries, please
> contact the 
> 

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Till Maas]

Hi,

On Fri, Dec 04, 2020 at 11:13:19AM -0800, Kevin Fenzi wrote:

> I don't think you can make branches completely descripive by themselves,
> unless possibly you make them really long. 
> 
> flatpak_branch_where_stable_flatpaks_are_made_from

That it is about flatpaks is already described in the namespace, that it
is a branch is clear from git. This only leaves "stable" as the one
information in the long name that would be missing.

> rawhide_its_the_branch_for_the_development_version_of_fedora_called_rawhide

It is fair to assume that someone who needs to use this already knows
what rawhide is. Otherwise they did not have any use for the branch,
even if it is called "main", so this long explanation does not make
sense, there.

> I suppose it's ok to make 'rawhide' a symref to main, or 'stable' in the
> flatpak case... 

"main" as a symref might help people that are used to using main.
Assuming that the symrefs are not visible, it makes more sense to use
the descriptive names for the branches such as rawhide/stable. Then they

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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Till Maas]

On Thu, Dec 03, 2020 at 08:52:13PM +0100, Pierre-Yves Chibon wrote:

> After looking at the infra and releng issue trackers Kevin managed to found 
> back
> the ticket I was thinking about.
> You have my apologies, the namespace that was asking to a different default
> branch and for that branch to not be named "rawhide" was flatpaks.
> They wanted the default branch to be "stable", which would not apply to most
> other namespaces. Thus the proposal to go with "main" which works for all
> namespaces and seems to be on its way to become the industry standard.

The flatpak namespace considering "main" to be the stable branch but
rpms considering "main" to be the development branch, is IMHO an
argument why we flatpack should use "stable" and rpms "rawhide". This
will make it more clear for everyone what the branch is actually about.

Using a ref to introduce "main" for muscle memory also sounds like a
good idea.

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

Re: Should the default editor be changed from vi to nano on upgrades to Fedora 33+

[Till Maas]

Hi,

On Thu, Dec 03, 2020 at 08:30:45PM +0100, Miro Hrončok wrote:

> Changing the default on upgrades is good because the Fedora 33+ experience
> is similar regardless whether the system is freshly installed or upgraded.

in this specific case, the argument for making nano default was that it
is easier to use than vi. In case of a system upgrade, the users are
already familiar with vi or changed their editor. Therefore it seems to
be more disturbing to change this default during upgrade.

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

Re: What is the real value of Release and %changelog metadata?

[Till Maas]

On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:

> Release tag problem/proposal
> 
> 
> Let's stop requiring Release bumps for each build.  And let's put an
> additional tag into Release, like proposed in [4]:
> 
> "Release: 1%{?dist}%{?buildtag}"
> 
> ... and let the build-system to put there an artificial (but increasing for
> subsequent build IDs) value.
> 
> Or alternatively, teach the build-system to enhance
> %dist in a similar fashion, as suggested in [5].

With this we will loose the ability to map RPM version information to a
SPEC file without querying Koji for the dist-git commit. Currently,
looking at dist-git allows to quickly check if there is a release there
than on a system. Not sure how useful it is but sometimes when I looked
into FTBFS bugs it was helpful to see that the last build did not match
dist-git which indicated that the SRPM creation failed in koji. Then it
looks like the package was never tried to be built. With those changes
it seems that dist-git will look untouched after a mass-rebuild.

Also, what about other special cases when using 0.1 for the release to
indicate pre-releases or git IDs for snapshots. How would  that look
like with your proposal?

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

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Till Maas]

On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote:
> Hi,
> 
> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git
> branch for Fedora Rawhide "rawhide" to clarify the purpose of that
> branch. There was also some feedback that Rawhide might not be the best
> name and it could be renamed. In that case, the branch could be named as
> this. This is just the first step to check if there is enough support
> for this to move forward. The next step would be to start a change
> process.

Just had another idea, how about instead of branch down from the rawhide
branch to new branched to make Rawhide always use the fxy version that
it develops. So instead of creating branched f33 later we would rename
master to f33 now and then once we need to branch we branch of Rawhide
as f34? There could still be a symbolic ref called rawhide for the
latest rawhide for convenience. What do you think?

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

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Till Maas]

On Tue, Jul 07, 2020 at 10:13:36PM +, Gary Buhrmaster wrote:

> I (strongly) support the renaming of the branch, but I really
> really would prefer there to be a rough consensus on the
> replacement name across the entire git community, so
> that I don't need to remember to git-checkout devel in one
> project, git-checkout trunk in another, git-checkout main in
> a third, git-checkout release in a fourth, git-checkout default
> in a fifth, etc.(*).  In this case, I would prefer Fedora follow
> the rough consensus presuming that one can be achieved
> rather than pick yet another (different) name.

There are several other branches than the branch for Rawhide that have a
name that is unlikely to be found in many other projects like f32, el6,
epel7, epel8-playground. Why is it more intuitive to use a name from
other projects as the name for the branch for Rawhide?

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

Using "rawhide" for the dist-git branch for Fedora Rawhide

[Till Maas]

Hi,

in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git
branch for Fedora Rawhide "rawhide" to clarify the purpose of that
branch. There was also some feedback that Rawhide might not be the best
name and it could be renamed. In that case, the branch could be named as
this. This is just the first step to check if there is enough support
for this to move forward. The next step would be to start a change
process.

In case you would like to help handling the effort that this needs, want
to highlight any tools that need to be adjusted (if they hard code the
branch name instead of querying it from some place) or have other
remarks, please add them here or in the ticket for FESCo to learn about
them.

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Till Maas]

On Tue, Jun 30, 2020 at 09:01:21AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jun 29, 2020 at 05:52:07PM +0200, Till Maas wrote:
> > On Mon, Jun 29, 2020 at 08:16:29AM -0400, Gerald Henriksen wrote:
> > 
> > > While it may be worth vim making themselves better, it really doesn't
> > > change the argument.
> > > 
> > > Even a friendlier vim is still going to be far to strange and
> > > confusing to somebody just looking to quickly change a setting and get
> > > on with Fedora.
> > 
> > The argument in the change proposal is that users might not know what is
> > going on when they run `git commit` and vi instead of nano is opened. It
> > does not mention "quickly changing a setting". Thinking more about this,
> > if someone has to use "git commit", they have probably changed
> > something with a tool. If this is a developer, they are probably using a
> > graphical IDE or a text editor on the console (or maybe a GUI text
> > editor).
> 
> > But I guess the IDEs usually have git integration, so the user
> > would then not use "git commit".
> Plenty of people use graphical editors without git integration. But
> even if the editor has integration, people will often have been taught
> or have learnt themselves to use a git from the command line and will
> continue doing that. In many ways the cli is more convenient, so if you
> once learnt that, you're unlikely to switch away.

IT seems that the persona that is targeted by this change is changing a
lot. Initially, it was about newcomers but someone who already learned
git from the command-line does not seem to be a newcomer.

> > If they already use a console editor,
> > would it be typical that they do not set the EDITOR variable?
> In my experience, people set $EDITOR very rarely.

So all those people are happy with vi? IMHO an argument for changing
this would be that a lot of people are already changing EDITOR to nano,
so it makes sense to make it a default. If this is actually not the
case it is not very convincing to change this.

> > And if they are using a graphical Editor, shouldn't maybe that one be
> > defaulted to in graphical environments?
> I replied to that earlier — short summary is that having the editor pop
> outside of the terminal window is confusing. We want the default editor
> to be in-terminal and block the terminal until the edit is done.

There can also be some text in the console that explains that the user
should look at the window for the GUI editor and the editor helper could
block the console until the edit is done. git-mergetool works just fine
with meld, for example. Also I know people using gvimdiff instead of
vimdiff.

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

Re: List of long term FTBFS packages to be retired in August

[Till Maas]

On Mon, Jun 29, 2020 at 05:21:58PM +0200, Miro Hrončok wrote:

>   Package (co)maintainers  Latest build
> 

> gpscorrelate   tillFedora 30

fixed.

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Till Maas]

On Mon, Jun 29, 2020 at 08:16:29AM -0400, Gerald Henriksen wrote:

> While it may be worth vim making themselves better, it really doesn't
> change the argument.
> 
> Even a friendlier vim is still going to be far to strange and
> confusing to somebody just looking to quickly change a setting and get
> on with Fedora.

The argument in the change proposal is that users might not know what is
going on when they run `git commit` and vi instead of nano is opened. It
does not mention "quickly changing a setting". Thinking more about this,
if someone has to use "git commit", they have probably changed
something with a tool. If this is a developer, they are probably using a
graphical IDE or a text editor on the console (or maybe a GUI text
editor). But I guess the IDEs usually have git integration, so the user
would then not use "git commit". If they already use a console editor,
would it be typical that they do not set the EDITOR variable?
And if they are using a graphical Editor, shouldn't maybe that one be
defaulted to in graphical environments?

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Till Maas]

Hi,

On Thu, Jun 25, 2020 at 06:48:56PM -0700, Adam Williamson wrote:

> Nothing in vi's default view (if launched with a file, which is what
> happens in this case) tells you you need to press 'insert' in order to
> actually edit anything. Nothing in vi's default view tells you you have
> to type the entirely cryptic sequence ":wq" to save and exit (or gives

since vim addresses this when opened without a file and it is open
source, it seems to me to be a good idea to propose to adjust vim
behaviour to show the help overview when opening a file as well. For
example if there is no ~/.vimrc or some other indicator that shows the
user does not know vim, yet.

Did someone discuss improving the novice user experience with the vim
developers, yet? What was the outcome?

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

Re: New set of questions for FESCo candidates?

[Till Maas]

On Thu, May 14, 2020 at 10:50:59AM -0700, Kevin Fenzi wrote:

> And perhaps it doesn't really provide more information, but it could. 
> 
> But I suppose without enough data people might not vote for people with
> too short / curt answers. Oh well, if people feel the explicit questions
> are better I won't stand in the way. :) 

I prefer the concise answer and having to read to much for too many
candidates would annoy me. So our preferences seem to be different,
here. There was one election where several candidates wrote very much...
So maybe add another questions like

Where can people find out more about you?

Then candidates can mention their blog, social media, ... to provide
more background information for the interested reader.

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

Re: New set of questions for FESCo candidates?

[Till Maas]

On Mon, May 11, 2020 at 01:37:08PM -0700, Kevin Fenzi wrote:
> On Mon, May 11, 2020 at 04:26:36PM -0400, Ben Cotton wrote:
> > On Mon, May 11, 2020 at 3:13 PM Zbigniew Jędrzejewski-Szmek <
> > zbys...@in.waw.pl> wrote:
> > 
> > >
> > > > 1. Why do you want to be a member of FESCo?
> > > > 2. How do you currently contribute to Fedora? How does that
> > > > contribution benefit the community?
> > > > 3. How should we handle cases where Fedora's and Red Hat Enterprise
> > > > Linux's needs are at odds?
> > >
> > > Hmm, that swings the pendulum very far in the other direction. The
> > > first two questions are about the candidate, and the last is about
> > > a very specific facet of community collaboration. There is no general
> > > question about current challenged or Fedora direction. Can we please
> > > include something like that too?
> > >
> > > Do you suggest dropping #1 or 2, or adding a fourth question?
> > 
> > Speaking for myself as an individual, I'm not convinced the current
> > challenges-type questions are entirely useful. In my experience, they
> > mostly serve as a way for candidates to express frustration but don't
> > result in proactive changes. I see the first question implicitly including
> > that question, so what if we made it more explicit:
> > 
> > 1. Why do you want to be a member of FESCo? How do you expect to help steer
> > the direction of Fedora?
> > 
> > (I don't love the wording, so I'll keep giving it some thought, but that's
> > the general idea)
> 
> Suggestion: Drop the set of questions entirely, replace with: 
> 
> Please write a short essay here describing your background, your past
> contributions to the Fedora Project, what you hope to accomplish, why
> community members should vote for you and any additional infromation you
> feel would be helpfull to community memebers.

Writing it as questions helps to write this because it will also make
shorter sentences. Basically you are telling people to answer questions
like the following, if I understand correctly:

What are your contributions to the Fedora Project?
What do you hope to accomplish?
Why should community members vote for you?
What else is helpful for community members to know about you?

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

Re: CPE Weekly: 2020-04-04

[Till Maas]

On Mon, Apr 06, 2020 at 08:35:28AM -0400, Alex Scheel wrote:
> - Original Message -
> > From: "Miro Hrončok" 
> > To: devel@lists.fedoraproject.org
> > Sent: Monday, April 6, 2020 8:28:15 AM
> > Subject: Re: CPE Weekly: 2020-04-04
> > 
> > On 06. 04. 20 14:19, Alex Scheel wrote:
> > > That part isn't actually clear to me. There's certainly a vocal portion
> > > against using GitLab
> > 
> > I think it's hard to see who's vocal against GitLab and who just wants a
> > truly
> > open decision process for this.
> > 
> > I've heard people who would love to get GitLab, but who are genuinely sad
> > about how CPE management handled this.
> 
> Sure, can we have two positions in this voting system?
> 
>  1. I want GitLab,
>  2. I want Pagure,
>  3. I want something not listed here,
>  4. I don't particularly care.

What do you want to do with this information? Also I do not think it is
a good idea to micro-manager CPE into a specific solution. IMHO it is
more important to get the dist-git features that Fedora requested and
probably also issue trackers for Fedora groups (for example Council,
FESCo, ...) currently implemented in
pagure.io), GIT repos with a git forge for Fedora (for example for docs,
infra, releng). And it would be great to also ensure that Fedora
contributors/Fedora Infra/CPE can contribute to these solutions to
ensure that Fedora specific requirements can be met.

If it is easier to customize Gitlab to meet Fedora's dist-git
requirements than to customize pagure, then it would be good for CPE
to do this even if more people would like to prefer pagure. If it is the
other way, then it could still make sense to use Gitlab for tasks used
by pagure.io to benefit from better Gitforge features, there, but keep
pagure for dist-git.

Also, I do not have any idea how easy it is to get changes into Gitlab,
so this is also something that needs to be taken into consideration.
I find it somewhat troublesome that these questions are not answered,
especially since the migration from pkgdb to pagure was very painful and
is not yet completed.

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

Re: CPE Git Forge Decision

[Till Maas]

On Mon, Apr 06, 2020 at 08:34:07AM -0400, Josh Boyer wrote:

> Why is it disappointing?  The Pagure project isn't suddenly being
> removed from the internet.  Is there a reason you can't contribute to
> it to add the features you need?

From my experience, I know that many of my contributions are triggered
by improving something that affects me. Therefore I submitted patches to
several Fedora Infra services when I was doing more packaging or rel-eng
work. As soon as pagure is not used anymore for Fedora's dist-git, at
lot of motivation to contribute it for Fedora contributors is gone.

I hope it will still be easy to contribute to the future dist-git
solution for interested Fedora contributors.

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

Re: Fedora 32 FTBFS packages to be orphaned in 1 week

[Till Maas]

On Mon, Apr 06, 2020 at 12:59:40PM +0200, Miro Hrončok wrote:
> On 29. 03. 20 13:13, Miro Hrončok wrote:
> > According to the Fedora's Fails To Build From Source policy:

> > Oprhaning is a easily revertible nondesctructiove action.
> > Only packages orphaned for 6+ weeks will be retired (removed from)
> > Fedora rawhide (i.e. not form Fedora 32).
> 
> Done.
> 
> Orphaned:

The orphaned packages still contain their previous co-maintainers. It
seems to me to make sense to remove them from the packages as well to
clarify who is really maintaining a package. Since the packages were
already in FTBFS for quite some time, there was enough time for a
co-maintainer to step in. In the normal case when a package is orphaned,
then the time for the co-maintainers to take over a package starts.

What do you think?

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

Re: The Git forge decision (was CPE Weekly: 2020-03-28)

[Till Maas]

Hi Leigh,

On Tue, Mar 31, 2020 at 09:56:10AM +0100, Leigh Griffin wrote:
> On Mon, Mar 30, 2020 at 10:13 PM Till Maas  wrote:
> 
> > Hi,
> >
> > On Mon, Mar 30, 2020 at 11:28:59AM +0100, Leigh Griffin wrote:
> >
> > > No singular Forge satisfied every single User Story. Any feature gaps
> > will
> > > land on the Backlog of Gitlab for voting and prioritisation as their
> > > Engineering teams see fit.
> >
> > this sounds very disturbing. Please clarify this.
> 
> 
> What part is unclear and I can help rephrase it? Leave me try in advance,
> no single solution would satisfy the entirety of the stakeholder needs
> across the board so our choice, Gitlab, satisfies the majority. They have a
> strong team who work on community requested features where we will log any
> feature gaps for their backlog and future consideration, further moving us
> to a point where all requirements are met.

What is unclear to me, is will CPE provide Fedora a solution for their
dist-git needs as described in the user stories provided by the Council?
Currently it sounds to me that CPE will only provide a generic git forge
and Fedora will rely on Gitlab to consider their special requirements
worthy to be implemented in a generic git forge solution.

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

Re: The Git forge decision (was CPE Weekly: 2020-03-28)

[Till Maas]

Hi,

On Mon, Mar 30, 2020 at 11:28:59AM +0100, Leigh Griffin wrote:

> No singular Forge satisfied every single User Story. Any feature gaps will
> land on the Backlog of Gitlab for voting and prioritisation as their
> Engineering teams see fit.

this sounds very disturbing. Please clarify this. Fedora needs a
dist-git repo with certain features/workflows that might not make sense
for a generic git forge or in other words: A git forge might just be a
part of the solution that Fedora needs for dist-git. Does this mean that
the CPE team will implement the missing features that are not part of a
gitforge and therefore no priority for Gitlab? Or will Fedora just get a
gitforge and need to figure out how to be able to implement their
workflows with it?

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

Re: CPE Git Forge Decision

[Till Maas]

Hi,

On Mon, Mar 30, 2020 at 02:40:13PM +, Leigh Griffin wrote:
> On Mon, Mar 30, 2020 at 3:26 PM Till Maas  wrote:
> 
> > Hi,
> >
> > On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote:
> > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas  wrote:
> > >
> > > > Hi,
> > > >
> > > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
> > > >
> > > > > For transparency, we have published the full User Story list which is
> > > > > linked within the blog and for ease of searching is here:
> > > > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
> > > >
> > > > the user stories list does not seem to include the original user
> > stories
> > > > that I submitted regarding package life-cycle and permission
> > management.
> > > > These are requirements for dist-git but not necessarily for a
> > git-forge.
> > > > In the past they were fulfilled by package db, now pagure is solving
> > > > this more.
> > >
> > >
> > > We received a summarised User Story list from the Fedora Council, I would
> > > suggest reaching out with your concerns.
> >
> > What is the list that you got. The list on the council discuss list
> > contained these items, for example for FESCo members, proven packagers
> > and dist-git repo admins:
> >
> > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
> 
> 
> We received a Google Doc with the summation of the 44 requirements from
> Fedora Council.

Please be more specific. Are these the requirements from the discussion
different ones? The discussion had 47 requirements, 1 and 2 were
challenged and 47 mentioned as nice-to-have. Who submitted them? I guess
it was Ben.

> > In the hackmd story list, there are is only infosec, RH Legal Rep, RH
> > Infocsec Rep, RH Developer, RHEL engineer and general users, project
> > contributor, CPE team member. Nothing really maps to the user groups I
> > mentioned.
> 
> 
> As mentioned, we rolled in stories together and General Users /
> contributors map to the majority of the Fedora projects requirements
> (similar for CentOS) and a lot of individual stakeholder requirements ended
> up in the general bucket.
> 
> 
> > There is only
> >
> > | 41
> > | As a General User
> > | I want groups and group membership and management
> > | to allow me create access control on a suite of repositories
> >
> > but this is very vague.
> >
> 
> The User Stories are deliberately vague and that represents around 10
> unique requirements that boil down to having group membership and
> management capabilities.

IMHO the problem with this vague requirement is that it probably fits
every gitforge. But for Fedora, the package management aspects are more
important than generic gitforge capabilities that any gitforge can
provide.

> > Also there seems to be nothing about orphaning/adopting/retiring
> > packages, not even in a vague way.
> >
> 
> We have stories relating to specific workflow requirements (from multiple
> stakeholders including RHEL, CentOS and Fedora) for dist-git. We have
> represented a requirement (number 18 on the list) about viewing orphaned
> packages. The requirements received around this process were very much
> aligned with permissions and visibility to allow actions. They are covered
> through other User Stories and what I feel needs to be made clear, we are
> presenting the amalgamated list and as a team we read every single User
> Story that came in and processed them accordingly in making this decision.

From the experience with the migration from Packagedb to pagure, the
specific requirements for Fedora seem to require more effort than just
providing generic gitforge capabilities. For example, the adopting an
orphaned package process needs to be a self service instead of a manual
process for release engineering. And the requirements seem to be so
vague that providing GIT repos with config files for workflows appears
as a valid solution but there should be a proper user interface.

Adapting a git forge to properly provide the workflow for Fedora
dist-git seems to me to be one of the major tasks, so assessing whether
a gitforge simplifies this seems to me to be rather important to make an
informed decision.

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

Re: CPE Git Forge Decision

[Till Maas]

Hi,

On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote:
> On Mon, Mar 30, 2020 at 2:18 PM Till Maas  wrote:
> 
> > Hi,
> >
> > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
> >
> > > For transparency, we have published the full User Story list which is
> > > linked within the blog and for ease of searching is here:
> > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
> >
> > the user stories list does not seem to include the original user stories
> > that I submitted regarding package life-cycle and permission management.
> > These are requirements for dist-git but not necessarily for a git-forge.
> > In the past they were fulfilled by package db, now pagure is solving
> > this more.
> 
> 
> We received a summarised User Story list from the Fedora Council, I would
> suggest reaching out with your concerns.

What is the list that you got. The list on the council discuss list
contained these items, for example for FESCo members, proven packagers
and dist-git repo admins:
https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/

In the hackmd story list, there are is only infosec, RH Legal Rep, RH
Infocsec Rep, RH Developer, RHEL engineer and general users, project
contributor, CPE team member. Nothing really maps to the user groups I
mentioned. There is only

| 41
| As a General User
| I want groups and group membership and management
| to allow me create access control on a suite of repositories

but this is very vague.

Also there seems to be nothing about orphaning/adopting/retiring
packages, not even in a vague way.

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

Re: CPE Git Forge Decision

[Till Maas]

Hi,

On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:

> For transparency, we have published the full User Story list which is
> linked within the blog and for ease of searching is here:
> https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8

the user stories list does not seem to include the original user stories
that I submitted regarding package life-cycle and permission management.
These are requirements for dist-git but not necessarily for a git-forge.
In the past they were fulfilled by package db, now pagure is solving
this more. What is the plan for this in the future? Will there be a
different solution instead of a git forge for this?

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

Re: GSoC 2020 | Improving Network Linux System Role

[Till Maas]

Hi Naman,

Thank you for your interest. Please take a look at:
https://github.com/linux-system-roles/network/wiki

Thank you
Till

Am Mi., 25. März 2020 um 04:36 Uhr schrieb Naman Dhingra
:
>
> Hello there,
> Hope this email finds you well!
>
> This is in with reference to the project idea of improving the N/W Linux 
> System Role shared on GSoC 2020.
> I would like to tell you that I really liked this idea of how we're trying to 
> uniformly handle the configurations for Network-Scripts and NetworkManager. 
> Moreover the thought to automate it via Ansible is a very good fit on a whole.
>
> Telling a bit about me, I'm a final year B.Tech CSE student, being Red Hat 
> Certified Specialist in Ansible Automation and some other tools, so I do have 
> the knowledge about the power of Ansible tool and how everything in it goes 
> on.
>
> I would really appreciate if you can share some more info. about this so that 
> I can prepare a proposal for it and submit.
>
> Looking forward to hearing from you.
>
> Thanks and regards,
> Naman
> ___
> Fedora Summer Coding community mailing list -- 
> summer-cod...@lists.fedoraproject.org
> To unsubscribe send an email to summer-coding-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/summer-cod...@lists.fedoraproject.org



-- 
Till Maas
He/His/Him
Associate Manager, Software Engineering
NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill,
Thomas Savage
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Autoclosure of review requests?

[Till Maas]

On Mon, Feb 24, 2020 at 05:04:26PM -0500, Ben Cotton wrote:

> The usual Bugzilla housekeeping (branching, EOL closure, etc) explicitly
> excludes review request bugs. Having a large number of open, ancient review
> requests isn't exactly harmful, but it's not very helpful either.
> 
> Before I make a proposal to FPC, I thought I'd open a conversation here.
> What does a reasonable cleanup of review requests look like?
> 
> My initial thought is to close all review requests that were opened >2
> years ago, to be performed at the EOL closure for each release.

Here are my thoughts: It depends on who is waiting.

If the submitter is not responding to a reviewer, it makes sense to
close the review request rather soon (maybe after 6 weeks).

If the reviewer is not responding after the submitter updated the review
request, the request should be unassigned to show that it is available
for other reviewers. This should happen rather soon for review requests
from new packagers (blocking NEEDSPONSOR) to keep newcomers on the hook
(maybe after 2 weeks).

If the review request is not moving forward in general, the submitter
should be asked if they still have interest and only if there is no
response, it should be closed. Maybe after 6-12 months.

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

Re: Turning off keys.fedoraproject.org

[Till Maas]

On Wed, Feb 12, 2020 at 11:15:01PM +0100, Björn Persson wrote:

> are sent over TLS, but what do they do if your email provider doesn't
> support SMTP over TLS? Do they refuse your key in that case? My guess
> is that they send the verification email unprotected, and that that's
> one reason why they say they're not a certification authority.

All CAs support verification via insecure protocols AFAIK because
usually the certificate is needed to secure the protocol. What other
option would they have?

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

Re: Git Forge Requirements: Please see the Community Blog

[Till Maas]

On Tue, Jan 21, 2020 at 04:34:37PM +, Leigh Griffin wrote:

> On behalf of the CPE team I want to draw the communities attention to a
> recent blog post which you may be impacted by:
>  https://communityblog.fedoraproject.org/git-forge-requirements/
> 
> We will be seeking input and requirements in an open and transparent manner
> on the future of a git forge solution which will be run by the CPE team on

Aleksandra's comment made me aware that for dist-git, we do not really
need a git forge, it is just that the pagure git forge was used to
implement a lot of workflows that pkgdb provided in the past.

I tried to write the requirements as user stories to make them easier to
understand. What do you think?

- As a package maintainer, I can only commit to a dist-git repo, if I am
  in the Fedora packager group.
- As a package maintainer, I can only commit to a dist-git repo, if I am
  a maintainer of the branch.
- As a proven packager, I can commit to all dist-git repos that do not
  have special restrictions set by FESCo or are retired.
- As a FESCO member, I can configure exceptions to disallow proven
  packager access to a dist-git repo.
- As dist-git repo admin, I can easily add other maintainers to allow
  commit or admin access for dist-git repo by using their FAS username
- As a dist-git repo admin, I cannot remove access to the repo from
  Fedora infra, Releng or proven packagers without FESCo approval.
- As a package maintainer, I can easily orphan a dist-git repo or branch
  to show that it is not maintained anymore.
- As a package maintainer, I can adopt any orphaned dist-git repo or
  branch.
- As a package maintainer, I can easily unretire a retired dist-git repo
  or branch.
- As a release engineer, I can easily approve unretire requests for a
  dist-git repo or branch.
- As anybody, I can easily see the FAS usernames of maintainers for all
  branches of a dist-git repo.
- As a non-releng member, I cannot remove any commits from any dist-git
  repo that were used to build a Fedora package.
- As an external user, I can easily get a list of all orphaned or
  retired dist-git repos and branches.
- As anybody, I can watch for issues (bugzillas) or PRs that are created
  for a dist-git repository.
- As anybody, I can easily get a list of all dist-git repos that I am
  watching.
- As anybody, I can easily get a list of all dist-git repos that a
  specific Fedora account has admin/commit access to.
- As anybody, when looking at the dist-git repo it is clearly visible
  which branches are still maintained.
- As anybody, when I look for a specific branch, EOL branches do not
  clutter my view.
- As a package maintainer, I can easily request commit/admin access for
  a specific branch or dist-git repo.

Also since dist-git is a critical part of our infrastructure, there
should probably also be some security-related requirements such as:

- As Fedora infra, I can easily audit that no git repo was accessed
  without authorization.
- As Fedora infra/security response team, I have access to secure logs
  to analyse the impact of unauthorized access to all dist-git repos.
- As anybody, the dist-git web page of a repo points me to Bugzilla to
  report issues for a repository.

I did not manage to read all other replies, so there might be some
duplicates but it also seems to me that many of these items were not
mentioned.

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

Re: Question about mass rebuilds

[Till Maas]

On Mon, Nov 25, 2019 at 10:33:54AM -0500, Steven A. Falco wrote:

> Yet according to koji, there is no build for fc31: 
> https://koji.fedoraproject.org/koji/packageinfo?packageID=avr-libc
> 
> I'm not saying that anything is wrong - I'm just curious as to why the 
> package wasn't rebuilt.  Any guidance/info would be appreciated.

One possible explanation is that creating the SRPM failed in Koji.
AFAIR, the rebuild will then not listed on the page you linked.

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

Re: Has fedpkg + dist-git replaced rpmbuild for building new/local packages?

[Till Maas]

On Mon, Oct 07, 2019 at 04:39:22PM +0200, David Kaufmann wrote:

> Although I have to re-symlink SOURCES everytime I work on a different
> package I can use all of rpmbuild, mock, fedpkg,… from the same source
> folder.

You can also use a wrapper script that can be called in dist-git working
copies to avoid the symlinking:

# rpmbuild-here.sh
# Wrapper around rpmbuild to use the current directory for everything
/usr/bin/rpmbuild --define "_sourcedir ${PWD}" --define "_rpmdir ${PWD}" 
--define "_builddir ${PWD}" --define "_srcrpmdir ${PWD}" --define "_speccdir 
${PWD}" "$@"

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

Please help with youtube-dl and possibly other packages of mine.

[Till Maas]

Hi,

Please help with updating youtube-dl and possibly other packages of mine 
because I cannot do it and my comaintainers do not seem to be able to do it as 
well.

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

Re: Using fedora-active-user: unable to find fedora_cert

[Till Maas]

Hi,

On Thu, May 30, 2019 at 09:43:38AM -0700, Kevin Fenzi wrote:

> Ideally it should drop fedora-cert use entirely. It looks like currently
> all it uses it for is to figure out your username. Instead it should
> default to your local user name or take a --user or something. :)

IMHO it should default to this:

if os.path.exists(os.path.expanduser('~/.fedora.upn')):
with open(os.path.expanduser('~/.fedora.upn'), 'r') as f:
username = f.read().replace('\n', '')
else:
username = getpass.getuser()

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

Re: Fork a 119MB pagure project to updating monitoring?

[Till Maas]

On Wed, Apr 10, 2019 at 11:04:11AM +0200, Pierre-Yves Chibon wrote:

> Basically, there would now be a button on the sidebar which would show the
> current monitoring status and would allow project admins and pagure wide 
> admins
> to update this setting.
> 
> Feedback most welcome :)

Awesome! Can we have such a plugin to claim orphaned packages as well,
please?

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

Stepping back from FESCo

[Till Maas]

Hi friends,

Brian[0] made me think about my commitments and I realized that it is
time to step back from my FESCo seat.

Thank you for your confidence in electing me last year!

Kind regards
Till

[0] https://www.winglemeyer.org/ramblings/2019/01/07/cookie-cleanup.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libravatar is in fedorainfracloud!

[Till Maas]

On Thu, Feb 21, 2019 at 09:40:16AM +0100, Michal Novotny wrote:

> We, as a libravatar group, are very happy that Fedora Infra provided
> us with the needed
> hardware. We will keep the service running by our own effort.

What is the right place report errors in the web server configuration
regarding the Strict Transport Security HTTP header? There are two
issues:

- it does not contain includeSubDomains
- http://libravatar.org odes not redirect directly to
  https://libravatar.org but to the www subdomain instead.

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Till Maas]

On Fri, Feb 15, 2019 at 04:28:17PM +0100, Vít Ondruch wrote:
> 
> Dne 15. 02. 19 v 14:22 Emmanuel Seyman napsal(a):
> > * Hans de Goede [15/02/2019 12:09] :
> >> And automatic scripts really just should hand it over to the first 
> >> co-maintainer
> >> in the list.
> 
> 
> As long as we have no idea if the other maintainers are active, I am
> strongly against the automation. I've been there. Followed nor
> responsive policy just to find out later that instead of orphaning the
> package, next inactive maintainer became owner. Very frustrating 

The advantage is that this will clean up the co-maintainer list
eventually.

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

Re: F30 Self-Contained Change proposal: MongoDB Removal

[Till Maas]

On Tue, Jan 29, 2019 at 04:23:48PM +0100, Miro Hrončok wrote:

> My understanding is that not only we will not able to test those, but there
> will be no point of shipping them at all. What am I missing?

It is very likely that the packages can still be used to access MongoDB
instances that run on other systems.

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

Re: Can we please stop enforcing Signed-off-by commits?

[Till Maas]

On Fri, Jan 18, 2019 at 08:14:32AM -0500, Stephen Gallagher wrote:
> On Fri, Jan 18, 2019 at 4:13 AM John Harris  wrote:
> >
> > On Friday, January 18, 2019 4:07:19 AM EST Richard W.M. Jones wrote:
> > > TIL - there's a git feature for adding S-o-B to a commit.
> > > I always typed it out by hand ...
> >
> > Not only that, but you can add an option to your either global or project-
> > specific .gitconfig to automatically sign off for you. I use this to
> > automatically sign (-S, not to be confused with signing off, -s) my commits.
> >
> 
> For the record, the option is:
> 
> format.signoff
> 
> A boolean value which lets you enable the -s/--signoff option of
> format-patch by default. Note: Adding the Signed-off-by: line to a
> patch should be a conscious act and means that you certify you have
> the rights to submit this work under the same open source license.
> Please see the SubmittingPatches document for further discussion.

This is only useful when using a mail workflow for submitting patches
because it does not affect commit afaik. There are other options for
commits, though:

https://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-using-format-signoff-not-working

Nevertheless, then it becomes mostly boilerplate IMHO.

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

Re: Organizing a "packager experience" objective and working group

[Till Maas]

On Thu, Jan 10, 2019 at 07:47:26PM -, Artur Iwicki wrote:

> - Now that I've mentioned it, maybe we should add something like "fedpkg 
> fas-login"? Personally I've put "alias koji-init='kinit 
> my-fas-acco...@my-domain.org'" in my .bashrc, because looking up how to solve 
> the "koji says I'm unauthenticated" error got boring after the third time.

IMHO you can take this one step further. Instead of telling that one is
unauthenticted it should start the authentication and ask for
credentials.

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

Re: Orphaned packages need new maintainers (will be retired in 1 week)

[Till Maas]

Hi,

Am 19.12.18 um 15:20 schrieb Miro Hrončok:

This should all be gone after I mass retire on Monday.
If the package is already retired but not known to be, retiring it 
again will make sure it is retired correctly.



it would be great to verify this. In the past I spotted some packages 
like these that did not get a branch on PDC and therefore could not 
properly be retired in PDC as well.



Kind regards

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

Re: How to avoid re-generating Pagure API keys all the time?

[Till Maas]

Hi Ben,

On Tue, Dec 11, 2018 at 11:42:51AM +0100, Ben Rosser wrote:

> I don't know. I feel like we could do a lot to improve the experience
> of packaging by investing time into fixing these sorts of minor
> annoyances. (But here I am complaining on the devel list and not
> actually doing anything to help, so I guess I'm part of the problem
> too).

you are right. I am thinking this, too. Would you maybe be interested in
making this a Community Objective[0] such as "Packaging Contribution
Experience"?

Kind regards
Till

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

Re: replace unclutter with unclutter-xfixes?

[Till Maas]

Hi Henrique,

On Wed, Nov 28, 2018 at 08:40:29AM -0800, Henrique Martins wrote:
> Unclutter seems to be an orphaned package that keeps being
> rebuilt, there even is an fc30 rpm.  The URL given in the
> fc29 package points to a dead link on MIT.  I filed a
> bugzilla report on this and no one replied.

the package is not maintained in Fedora anymore and going to be removed,
soon. Would you be willing to maintain it in Fedora?

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

Re: Orphaned Packages in rawhide (2018-09-07)

[Till Maas]

Hi,

On Fri, Sep 07, 2018 at 11:07:02AM +0200, Vít Ondruch wrote:
> When is this going to happen? Because I'm still concerned with the
> js-jquery1 and I still hope somebody else will pick it up. But if not,
> I'd rather pick it up prior its retirement.

I guess we will discuss this in the next FESCo meeting.

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

Re: Orphaned Packages in rawhide (2018-08-27)

[Till Maas]

On Tue, Aug 28, 2018 at 04:04:37PM +0200, Vít Ondruch wrote:

> I'd like to keep the packages above.
> 
> And I'll be very happy if the packages listed bellow are retired. Most
> of them are orphaned without comaintainers, that is fine. However some
> appears to have co-maintainers, which is not really the case. I.e:
> 
> Michale Stahnke (stahnma) -
> http://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VBUPHRBDMQTF44FJX2ABXCIVDMKV3SXP/
> ruby-packagers-sig - Obviously I hope this group won't become dumping
> ground of packages which nobody wants/maintains, because although I am
> admin of that group, I'm not sure I can retire the packages. I am pretty
> sure I cannot drop the commit bit for that group.

If you have commit access, you can retire the packages because "fedpkg
retire" will just add the dead.package file and the remaining actions
should happen automatically internally.

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

Re: Orphaned Packages in rawhide (2018-08-27)

[Till Maas]

Hi,

On Tue, Aug 28, 2018 at 11:00:54AM +0200, Bob Mauchin wrote:
> 
> Can someone reassign dnscrypt-proxy to me, eclipseo, I have updated the
> project recently and I follow upstream closely. What's the procedure to
> adopt it?

I assigned it to you. The usual process is to file a releng ticket at
https://pagure.io/releng/new_issue

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

Re: Orphaned Packages in rawhide (2018-08-27)

[Till Maas]

Hi,

On Tue, Aug 28, 2018 at 04:56:58PM +1000, Dan Callaghan wrote:
> Excerpts from Till Maas's message of 2018-08-28 00:03 +02:00:
> > python-configobj   fale, lmacken, orphan, 45 weeks ago  
> >terjeros 
> [...]
> 
> I will take python-configobj if nobody else will... BUT I don't quite 
> understand what this means.
> 
> Pagure shows the owners as:
> 
> orphan (orphan) - main admin
> Fabio Alessandro Locati (fale) - admin
> lmacken (lmacken) - admin
> Terje Røsten (terjeros) - commit
> 
> The package has no open bugs and is not failing in Koschei so I do not 
> see any reason why it needs to be retired.
> 
> What does it mean for a package to be owned by orphan while it still has 
> other admins who are real people?

Technically it means that new bug reports will not be assigned to any of
these admins but the orphan user. It will make the support status of the
package unclear for everyone looking at it. For example Luke (lmacken)
does not appear to be active in Fedora anymore (IIRC there was also a
non-responsive maintainer process initiated).

> Is this some kind of edge case where the package was owned by 
> a maintainer who was inactive, and thus their packages got "orphaned", 
> even though there are still other maintainers? Is there any record where 
> we can see when or why these changes were made?

Unfortunately, there does not seem to be a record anymore since pkgdb
was retired. I assumed it would be visible in fedmsg/datagrepper but it
does not seem to be. However, this might also mean that co-maintainer do
not get a notification when a package is orphaned.

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

Re: "Orphan packages will be retired if they remain orphaned for six weeks"

[Till Maas]

On Thu, Jul 26, 2018 at 10:38:33AM +0200, Miro Hrončok wrote:
> Is $subj [1] an automated or manual process? Shall I retire packages I've
> orphaned before more weeks or just wait?

Please retire the pkgs yourself. This is currently not happening. The
deprecation of pkgdb broke the script and the new setup did not support
orphaning on a per-branch level.

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

Re: [HEADS UP] Removal of GCC from the buildroot

[Till Maas]

On Fri, Jul 13, 2018 at 12:39:55PM +0200, Igor Gnatenko wrote:

> Yes, I've pushed over 2k commits adding those, however regexp might have
> not catched all possible cases. Would appreciate if you would link such
> packages so that I can fix them. Or maintainers can do it themselves.
> 
> [1] https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html

Can you maybe add:

g?cc: [Co]mmand not found

to the script, regrep and fix the resulting packages. I just checked 3
of 12 of my failed pkgs and they had error messages like the following:

| make[1]: gcc: Command not found
| sh: gcc: command not found
| make: cc: Command not found
| 
| https://kojipkgs.fedoraproject.org//work/tasks/215/28320215/build.log
| https://kojipkgs.fedoraproject.org//work/tasks/9137/28229137/build.log
| https://kojipkgs.fedoraproject.org//work/tasks/4199/28314199/build.log

If you have the tools ready, it would make it easier to just re-run it
IMHO.

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

Re: [HEADS UP] Removal of GCC from the buildroot

[Till Maas]

On Tue, Jul 10, 2018 at 05:44:50PM +0200, Kevin Kofler wrote:

> I still think that this change is absolutely counterproductive, because it 
> will actually INCREASE local mock build times for all C/C++ programs for all 
> packagers, because gcc and gcc-c++ will no longer be included in the root 
> cache.

If you or someone else cares about this for their own setup I recommend
to change or add a mock config that just extends the chroot_setup_cmd to
include gcc and gcc-c++ and the problem is solved.

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

Re: Packages which needlessly use %defattr

[Till Maas]

Hi,

On Tue, Jul 10, 2018 at 10:36:08AM -0500, Jason L Tibbitts III wrote:

> I haven't written any scripts which modify specfiles, only scripts which
> find issues.  And in any case:
> 
> https://fedoraproject.org/wiki/Mass_package_changes#Automated_cleanup
> 
> Besides... this is git.  And rawhide.  If I broke something seriously
> then I or any maintainer or any provenpackager can revert the commit.
> 
> Really, if we just waited until every spec maintainer had a chance to
> ack every script that's used to modify packages, there would be no point
> in ever trying to do automated cleanup.  Sorry, but my work with Fedora
> will be aimed towards progress, not sitting around not changing anything
> for fear of potentially breaking something.
> 
> The removals of %defattr that I did a few hours ago were done by hand,
> not scripted.  I don't doubt that there's a reasonable chance that I
> could have screwed up one or two out of nearly 2700 packages.  That's
> life.

thank you Jason for doing this. IMHO we need to embrace this approach.
As you write, it is the path for progress and I hope we have more of
these automatic cleanups to reduce the need for manual interventions as
much as possible.

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

Re: [HEADS UP] Removal of GCC from the buildroot

[Till Maas]

Hi,

On Tue, Jul 10, 2018 at 08:42:09AM +0100, Tomasz Kłoczko wrote:

> At the bottom I want only flag that people like Igor as they have
> proven packager perms are able to make at the end more harm than good.
> I don't know him (how experienced developer he really is) as my only
> personal contact with him was when on IRC he asked me where my texinfo
> PR and bugzilla ticket are.
> If some wide changes so badly prepared and conducted will happen again
> IMO someone at least should consider withdraw his proven packager
> privs.

I am glad for Igor doing this work and he is doing a lot more good than
harm.

> kloczek
> PS. And really I don't care that again above will be taken as kind of
> personal attack (which is not my intention).

The Fedora Code of Conduct is not optional therefore I expect you to
care about this. If you believe your e-mail might be offensive, it is
your job to ensure that it is not.

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

Re: New FESCo Meeting Time and Ticket Policy

[Till Maas]

On Tue, Jun 19, 2018 at 01:18:04PM +0200, Vít Ondruch wrote:

> Although still, the FESCo meeting agenda used to be place, where it was
> obvious, that something probably happened with the ticket and it needs
> FESCo (and possibly my) attention. The notification of new issues would
> not replace the convenience FESCO meeting agenda, but better than nothing.

To address your concerns we will mention the resolved tickets since last
meeting the agenda for the next meeting, so you can bring them up in the
open floor if necessary.

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

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

[Till Maas]

On Fri, Jun 22, 2018 at 07:24:54PM +0200, Björn Persson wrote:
> Till Maas wrote:
> > I do not see any reason why a user would put something in ~/bin that
> > would mask something in /usr/bin except to actually mask the binary. It
> > is the same with other user configuration, anyone expects ~/.ssh/config
> > to override /etc/ssh/ssh_config instead of the other way round.
> 
> It could happen by accident. A user might put a program in ~/bin that
> happens to have the same name as one in /usr/bin that the user is
> unaware of, and it might break other programs which call that command
> without a full pathname. Editing ~/.ssh/config affects only SSH, and
> isn't likely to break something unrelated.
> 
> That's one reason why I'm not convinced that this change is a good
> idea. It obviously has nothing to do with security though. It's a
> matter of safety, which is different from security.

In your opinion, how does the user act nowadays when something in
/usr/bin masks their tool that they installed in ~/bin? I would assume
that they will change the path, since installing the tool there is what
they wanted. Making it hard for users to achieve their goals usually
does not stop them. Also a tool with a same name in /usr/bin might also
break another user's tool that expects the user version to be available
in the PATH. I do not see how this would be better. And it might also
happen with aliases or functions that users would configure in
~/.bashrc. I know that bash-completion using the _* namespace broke a
lot of shortcuts that I used (and I still think it is sad that this easy
to use prefix (at least on a QWERT* keyboard) was made unusable, even
though these are identifiers nobody needs to type).

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

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

[Till Maas]

On Fri, Jun 22, 2018 at 05:01:38PM +0100, Tomasz Kłoczko wrote:
> On Fri, 22 Jun 2018 at 13:36, Till Maas  wrote:
> [..]
> > > The attacker could have looked up the exploit on the web.
> >
> > If it is a public exploit, then it is usually fixed by updates,
> > especially if the impact is that big. A user not installing
> > security updates is a scenario I consider not worth to explore, since
> > there might be all kinds of serious vulnerabilities.
> 
> Just FTR.
> If Fedora maintainers will decide to put ~/.local/bin over /usr/bin on
> the $PATH it will be possible to control over ~/.local/bin/id (and/or
> many more similar commands) what happens on begin of the user login
> session. None of the packages updates (except that one which will
> remove ~/.local/bin/ from the $PATH) would be able to stop damage ones
> done.
> 
> Would you consider now classify such change as serious vulnerability
> introduction?

No, the vulnerability is whatever allowed attackers to get write access
to $HOME. And there would be a lot more changes to $HOME or other paths
in a real-world attack that an update could not fix. Also I guess most
attacks target information, computing power or network access and there
is no way to revoke this with an update after the attack was successful.
And the best practice to cleanup after an attack is to reinstall from
known-good sources.

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

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

[Till Maas]

On Mon, Jun 18, 2018 at 02:17:43PM +0100, Tomasz Kłoczko wrote:

> For example in case of have /usr/local/bin/id you can observe that
> gnome-terminal started from command line and GUI menu are altere.
> In other words this effect is literally spreads as well across most of
> the /usr/share/application/*desktop files (just grep those files for
> ^Exec=).
> Using in Exec= only binary name instead full path would be nothing bad
> .. however this mixed with currently used $PATH really changes
> everything!

No, it does not change everything as attackers can also just copy
desktop files with other Exec-Keys to

/home/till/.local/share/applications, for example like this:

sed -e s,Exec=.*,Exec=xmessage\ pwned,
/usr/share/applications/firefox.desktop >
~/.local/share/applications/firefox.desktop

There is no need to drop something in the path to manipulate desktop
files/the applications that are started (I verified this with Gnome on
Fedora 28). Please stop with these false claims.

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

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

[Till Maas]

On Sat, Jun 16, 2018 at 01:17:57PM -0400, Nico Kadel-Garcia wrote:

> * Stolen passwords from penetrated hosts, used for SSH connections.
> Copying a file to $HOME/.local/bin requires far less scripting and
> awareness of existing contents than editing of .bashrc or .profile
> that reveals timestamp changes of the edited file, and differs from
> system defaults. Since the contents of $HOME/.local/bin are not
> defined or definable, by its very nature, it's harder to audit.

The system default would be that they are empty or contain the files
that are put there by default. Not really harder to audit that a .bashrc
file. Also if you can use SSH to access the system, you can just execute
commands. If you can only copy files, why is copying content to ~/.i18n
less bad?

> * Fileshares of home directories. Many environments, especially
> university environments, use NFSv3 with quite general access. Welcome
> to write access to $HOME/ !!!  And $HOME/.local/bin is notably less
> apparent than $HOME/bin, due to the default lack of "ls" reporting of
> contents of "." prefaced directories, and of the difficulty of leaving
> security auditing to check .bashrc, .profile, etc.

Still, why would an attacker then copy something to these directories
instead of to ~/.i18n, or ~/.ssh/config or ~/.vimrc? Also if you want to
do a proper audit of all executables in the PATH the first step would be
to check the value of $PATH because this is something an attacker could
also change to any other value that would need to be checked. And once
you look at $PATH, ~/.local/bin is no longer hidden because it is in
plain sight there, even easier to spot when it is at the beginning.

> Does that give you enough examples of unnecessarily vulnerable vectors
> opened by default by the casual assumption that "ohh, they could get
> in another way, so I don't have to worry about the hole *I* am
> suggesting opening up!!!"

No, in your examples $HOME would be compromised anyhow already.

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

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

[Till Maas]

On Fri, Jun 15, 2018 at 06:56:16PM +0200, Alois Mahdal wrote:
> 
> 
> On 06/15/2018 11:24 AM, Till Maas wrote:
> > ...]
> > 
> >> What I'm trying to say is that with these kinds of attack (like viruses,
> >> or exploits on massively accessed page), there is inevitably going to be
> >> some sort of economic decision on side of author affecting how "smart"
> >> they want the code to be.
> >>
> >> Thus, every little step you're making towards "easier" translates to
> >> dumber exploits being able to succeed.  Suddenly not just those that did
> >> 2 things but also those that did 1 thing.
> > 
> > So the assumption is to have a super sophisticated browser exploit for
> > which an attacker most likely spent several days to find it and then the
> > PATH setting will make it so much harder that the exploit will not
> > succeed? There are a lot more real challenges that attackers have to face.
> 
> The attacker could have looked up the exploit on the web.

If it is a public exploit, then it is usually fixed by updates,
especially if the impact is that big. A user not installing
security updates is a scenario I consider not worth to explore, since
there might be all kinds of serious vulnerabilities.


> I think you keep putting some kind of base standard on the hypothetical
> attacker and then your argument is "if they can do X then they can do
> Y".  Because we're both SW engineers, the relation between X and Y is
> obvious to us, so yeah, anybody who would do X would totally obviously
> also do Y.  Sure, we've been there so many times we don't even think
> about it.

This is a useful way to categorize security vulnerabilities because they
should allow an attacker to gain more privileges/possibilities/... And
if we assume that a system is secure because people do not know about
other possibilities, then it is security by obscurity which does not
work in practice.

> OTOH, I don't think that's the best way to think about security.  There
> are no standards.   The amount of code (dedicated to Linux) could
> totally be just that single line, writing the payload to .local/bin.
> By including the path in default $PATH, you are allowing also the
> on-bit-dumber attack to succeed (... now with all Fedora users, yay!...)

Is this realistic? There a endless other possibilities and there is no
reason why an attack to access exactly these directory paths is more
likely than the many other possibilities. Also why would attackers
choose this path in the first place? Putting a new ~/.i18n file in the
user's home directory seems to me to be more likely to succeed.

> I'm saying there is some impact.  I'm not aware of any meaningful way to
> measure it, but I don't think it's necessary: IMHO even making a "minor"
> impact is already bad idea.

I do not agree because the way you argue could be applied to anything
and there could always be the one imaginary exploit that will have a
payload that will only work because of $whatever and therefore make in
impact. For example from the other changes, what if there is a payload
that uses a feature of Golang 1.11 or a bug that is fixed in Binutils
2.31.

> Especially if I don't really see any convincing reason why this should
> be done.

I do not see any reason why a user would put something in ~/bin that
would mask something in /usr/bin except to actually mask the binary. It
is the same with other user configuration, anyone expects ~/.ssh/config
to override /etc/ssh/ssh_config instead of the other way round.

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

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

[Till Maas]

Hi,


Am 15.06.2018 um 00:50 schrieb Alois Mahdal:


On 06/14/2018 11:37 PM, Till Maas wrote:

Hi,

On Thu, Jun 14, 2018 at 04:19:27PM +0200, Alois Mahdal wrote:


On 06/14/2018 08:40 AM, Zbigniew Jędrzejewski-Szmek wrote:
What about attack success rate?
But if the attacker is some browser exploit able to take a shot at many
users (not knowing what their OS, let alone default $PATH is), then I

The browser knows the OS, see the User-Agent header, for example:
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Name

Also the PATH would be in the browser environment, so easy to access,
too. However, if this information is not available to the attacker, why
would they know the value of $HOME/bin or $HOME/.local/bin? They would
have to know the user's username for this. IMHO these are not convincing
assumptions.

Those are not assumptions.  It would be incorrect to assume that.


I do not follow here because these assumptions are made by you in your 
argumentation as far as I can see.



What I'm trying to say is that with these kinds of attack (like viruses,
or exploits on massively accessed page), there is inevitably going to be
some sort of economic decision on side of author affecting how "smart"
they want the code to be.

Thus, every little step you're making towards "easier" translates to
dumber exploits being able to succeed.  Suddenly not just those that did
2 things but also those that did 1 thing.


So the assumption is to have a super sophisticated browser exploit for 
which an attacker most likely spent several days to find it and then the 
PATH setting will make it so much harder that the exploit will not 
succeed? There are a lot more real challenges that attackers have to face.




Most users will use .bashrc and since it would be the file that is under
discussion here, only users that use it would be affected by the change.
Also attackers do not need a fancy algorithm, they can just manipulate
several files instead of doing sophisticated checks.

Even manipulating one, let alone several files, is already more
sophisticated than merely dropping one file.


echo echo pwned >> ~/.i18n does both (appending or creating a file, not 
really more sophisticated). And this just works regardless of the PATH 
setting.




If I was writing malware, I would be much happier with just being able
to drop a file in ~/bin or ~/.local/bin than doing the research on where
PATH is actually being set, and then getting the `sed` right, and all
that **without** being immediately discovered (eg. because I broke the
syntax or caused error).


If the attacker can already call sed, then they do not need to drop a 
binary. Also they do not need to research where PATH is actually set.



My point is that security is not a black & white concept.

It's a float, not a bool.  And I'm not arguing about the amount, but
merely against the black & white thinking.  With all respect, to me it
sounds  kinda like saying "why wash my hands when diseases can spread
through air".


The initial theory in this thread was that it is a significant security 
risk. And all the arguments for this are either "it's obvious" or are 
based on arbitrarily constructed scenarios. If you are saying it just 
makes a minor impact, then we do not need to discuss further because 
this is good enough for me.


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

Re: FESCo Elections - May 2018 : Results announcement

[Till Maas]

On Thu, Jun 14, 2018 at 04:53:58PM -0500, Dennis Gilmore wrote:

> Theory will always become reality at some point. I think there is very
> good reasons to keep the staggered approach to electing FESCo members. 

The lack of candidates and voters is a practical problem that we have
now. Not sure if reducing the amount of elections would help, though.

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

Re: FESCo Elections - May 2018 : Results announcement

[Till Maas]

On Thu, Jun 14, 2018 at 08:02:33AM -0500, Michael Cronenworth wrote:
> On 06/14/2018 03:42 AM, Pierre-Yves Chibon wrote:
> > I know we never manage to motivate many people to vote, but 86 votes is 
> > really
> > low, even for us:(
> 
> Yes, I was checking out the voter count on other pollings and the turnout is
> around 100. Disappointing. :(
> 
> Lack of awareness or advertising? I voted.

I assume lack of badges for voting, misalignment with the other
elections and not enough contributors/candidates.

Also in the past there were wore blog posts about people who voted on
planet etc.

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

Re: FESCo Elections - May 2018 : Results announcement

[Till Maas]

On Thu, Jun 14, 2018 at 03:57:36PM -0400, Josh Boyer wrote:
> On Thu, Jun 14, 2018 at 3:53 PM Randy Barlow

> > Downside is that it would be possible (though I'd guess unlikely) for
> > all of FESCo to suddenly change to 9 different people and there'd be no
> > members who know the current state of things. We would also need to do
> > something a little awkward to get into this state since we currently
> > have staggered terms.
> 
> The election structure was setup specifically to avoid this problem.
> The alternative solutions were all pretty poor.

This seems to be a very theoretical problem because it would mean that
we have nine times the number of new candidates that we have now and
everyone is so unsatisfied with FESCo that only new candidates will be
elected. And if there is so deep dissatisfaction, a fresh start might
even be a good idea. Also there would still be other people around to
provide guidance or there is another problem.

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

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

[Till Maas]

Hi,

On Thu, Jun 14, 2018 at 04:56:32PM -0400, Stephen John Smoogen wrote:

> Look, people keep asking why it was like this. I am trying to explain
> it. I am not defending it or saying we have to keep doing it that

Thank you very much. I appreciate it to know the history and see that I
am not missing something important. It is now considered and we seem to
agree about the irrelevant security implications for current systems.

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

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

[Till Maas]

Hi,

On Thu, Jun 14, 2018 at 04:19:27PM +0200, Alois Mahdal wrote:

> On 06/14/2018 08:40 AM, Zbigniew Jędrzejewski-Szmek wrote:

> What about attack success rate?

> But if the attacker is some browser exploit able to take a shot at many
> users (not knowing what their OS, let alone default $PATH is), then I

The browser knows the OS, see the User-Agent header, for example:
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Name

Also the PATH would be in the browser environment, so easy to access,
too. However, if this information is not available to the attacker, why
would they know the value of $HOME/bin or $HOME/.local/bin? They would
have to know the user's username for this. IMHO these are not convincing
assumptions.

> believe every next, more sophisticated step is less likely to be
> included.  For example, they might not really feel it worth to include a
> working algorithm to look at whether user uses .bashrc, .xsessionrc,
> .zsh, .profile or whatnot.  Ie., leaving out ~/.local/bin would result
> in **worse success rate** for them.

Most users will use .bashrc and since it would be the file that is under
discussion here, only users that use it would be affected by the change.
Also attackers do not need a fancy algorithm, they can just manipulate
several files instead of doing sophisticated checks.

And again, as I already wrote, either ~/.bashrc is affected or not, you
cannot properly argue that it is affected in the way that it is read to
set he path but is not affected in the way that it will not be read
anymore after an attack.

>  *  (A) user doing something and knowing what & why,
>  *  (B) user copy/pasting some info from (untrusted?) github README.md,
>  *  (C) an (untrusted?) program run by user intentionally,
>  *  (D) malware running via exploit.
> 
> And if you make the change in $Subj, you can only make it for all of the
> above or none.
> 
> Inconvenience is not that much of a problem for (A), because it's not
> likely that they would know what they're doing and not recognize why
> it's not working (and blame Fedora).
> 
> Making it more convenient for (B) and (C) is IMO not worth given that
> we'd also make (D) more likely to succeed.

If there is already malicious code running with access the user's home
directory, the PATH setting is the least problem for the user because
the assumed problem for the PATH setting was that it would allow
attackers to get code executed.

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

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

[Till Maas]

On Wed, Jun 13, 2018 at 05:28:03PM -0400, Stephen John Smoogen wrote:

> The usual culprit in the past has been where an attacker gets access
> via a chrooted or container environment where they only have access to
> a limited set of directories. A long time ago this was done via ftp

I read this as there is an actual security vulnerability to begin with.

> and some other remote filesystem which were common in universities and
> thought safe by itself. Or the attack would be done by controlling one
> host with root permissions and using NFS or some other global
> filesystems to put a trojan in one system and then getting the admin
> to execute it on a different system. This was why it was a security

I do not follow why the attacker would only have access to ~/bin or
~/.local/bin and can only add files there but not read or modify other
files.

> finding for a long time in various checklists that user controlled bin
> directories needed to be at the end of the path. It was also linked to

IMHO "it is on a checklist" without proper justification is probably
just security theater. There are enough possibilities to manipulate
files in $HOME and it usually contains the important user data so that
it should be protected properly so that one can properly assume that
only the user or administrators can access the data therein. AFAIK
selinux does this already and admins need to explicitly label
directories to allow protected services to access them. And this
whitelisting approach is the right thing to do from a security
perspective instead of trying to blacklist useful features for a
IMHO negligible or imaginary security gain.

All in all, there are already a lot of possibilities to escalate from
write access to $HOME to code-execution regardless of ~/bin or
~/.local/bin that I strongly believe that $HOME needs to be secured and
considered to be safe for their user. Otherwise I would like to see CVEs
for ~/bin being already in the PATH, since it can still contain typos of
common commands or commands that are not yet installed (and there is a
package kit plugin that shows that people will type commands of packages
that are not yet installed), for ~/.i18n (try test -e ~/i18n || echo
echo pwned > ~/.i18n if you wonder why), for ~/.ssh/authorized_keys to
allow login access for local users or ~/.ssh/config for allowing the
ProxyCommand directive. There are endless possibilities here.

> the reason not to put . in the path.

If there is a directory in the PATH that is controlled by other users,
it is very likely a problem, therefore adding "." there is bad.

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

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

[Till Maas]

On Tue, Jun 12, 2018 at 08:43:06AM -0400, Matthew Miller wrote:
> On Tue, Jun 12, 2018 at 07:50:29AM -0400, Nico Kadel-Garcia wrote:
> > The simple fact is that "sudo" inherits $HOME and $PATH by default.
> 
> Not in Fedora's default configuration. And, this proposal increases my
> support for keeping that as it is (with secure_path set).

I did not see a convincing argument or explanation why there is a
critical security issue with sudo and this change, even when sudo would
inherit $HOME and $PATH. Who is the attacker that can drop files only in
$HOME/.local/bin or $HOME/bin not not in other directories, cannot
append existing files and does not yet have elevated access on the
system.

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

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

[Till Maas]

Hi,

On Wed, Jun 13, 2018 at 06:28:47PM +0200, Alois Mahdal wrote:

> I've seen many examples with .bashrc, but .bashrc only does it for bash
> (and only in interactive mode, IIRC).  One has to do it for something
> like .xsessionrc -- frankly I'm not sure if there is such file that applies.
>
> OTOH, by adding .local/bin, the attacker does not have to care where (or
> how) to set the path, they really only need to drop new file.

we are talking about a change in ~/.bash_profile here which sources
~/.bashrc. If you are thinking of scenarios where these files are not
sourced, then the PATH is not changed in that scenarios. Therefore these
scenarios would not matter here.

Also from an attacker's perspective: The attacker can just change
multiple files if necessary.

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

Re: Elections for Council - May 2018 - Result announcement

[Till Maas]

Hi,

On Thu, Jun 07, 2018 at 09:06:34AM -0400, Matthew Miller wrote:
> On Thu, Jun 07, 2018 at 04:34:10AM +0200, Jan Kurik wrote:
> > The elections for Council - May 2018 [1] have concluded, and the
> > results are shown below.
> 
> Welcome, Till! And, thank you Nick for your work on the Council over
> the last year. I really appreciate the perspective and thoughtfulness
> you brought to the role.

Thank you very much Matthew  and thank you Nick for your service! You are
a very engaged contributor and I would have loved to serve the Council
together with you!

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

Re: Fedora Elections May 2018 - Voting period of FESCo elections has started

[Till Maas]

On Fri, Jun 08, 2018 at 12:04:29PM -0400, Randy Barlow wrote:
> On 06/08/2018 11:54 AM, Ben Rosser wrote:
> >> you can ask Koji to build off the master branch for non-rawhide
> >> releases.
> 
> > I actually didn't know this. Is this a recently added feature? Is
> > there some place I can read about it?
> 
> I don't believe it is recently added, though I don't know Koji's
> history. I suspect it's been like this a long time though. I don't know
> it to be documented, I kinda just discovered it on my own. Basically, I
> noticed that "fedpkg build" really just calls Koji, and asks it to build
> a particular commit for a particular tag. For example, have a look at
> the "Source" field at:
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1084812
> 
> It's
> git+https://src.fedoraproject.org/rpms/bodhi.git#9db03db15d7c9631887c759cc6bf19e0a1f4b241
> 
> That happens to be on Bodhi's master branch right now. So I could ask
> Koji to build that commit for f27 like this:
> 
> $ koji build f27
> git+https://src.fedoraproject.org/rpms/bodhi.git#9db03db15d7c9631887c759cc6bf19e0a1f4b241

It is possible, but it will break when someone else will have to rebuild
something else than Rawhide and make a change there. Also it will
irritate people who are looking for sources for a package.

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

Re: Fedora Elections May 2018 - Voting period of FESCo elections has started

[Till Maas]

Hi,

On Thu, Jun 07, 2018 at 05:15:04PM +0100, Tomasz Kłoczko wrote:

> No one points on things like discussion on:
> - common specs coding style
> - cutting number of %iffings (and use instead SCM branches which git offers)
> - cutting legacy tails like still using tons of scriptlets which can be
> easily cleaned of remove dependencies on initscripts and maaany more like
> this which could make at least @core solid fundamentals other features
> - cutting number of dependencies (how many years ago was first discussion
> about use --as-needed in linker options?)

for this we need people to actually to the work. As a FESCo member it is
possible to support initiatives for this and I support a more
collaborative package maintainership that enables contributors to easier
to mass changes to improve packages. Nevertheless without someone
interested to do the ground work we will not get there.

> - caring about quite basic security (look decision about add ~/.local/bin
> to the $PATH and complete kind of "desinteressement" about remove
> /usr/local/{bin,sbin} from already used $PATH which widely opens hell gates
> for malwares).

You should not confuse disagreeing on the security implications of a
setting with not caring about security. And it is best practices to
provide a proof-of-concept when reporting a security issue. If you show
one that allows to to get access to a web server that serves this CGI
script:

---
#! /usr/bin/bash

PATH=${HOME}/bin:${HOME}/.local/bin:/usr/local/bin:/usr/local/sbin:${PATH}
id
---

This was vulnerable to Shellshock, a serious security vulnerability. I
am very interested to see how changing the PATH changes makes it
significantly easier to exploit this script.

> Second most important goal on which candidates are focused is how internal
> Fedora infrastructure works.
> 
> No one of the candidates seems is aware that people are leaving Fedora boat
> (look on distrowatch.com or
> https://w3techs.com/technologies/details/os-linux/all/all and few other
> similars stats) not because Modularity still doesn't work (and will never
> work as no one will not change some fundamental bits in rpm). Most of the

What is the reason for this in your opinion?

> candidates seems are completely unaware that end users of they work (binary
> packages) simple don't care about how all Fedora stuff is build but HOW IT
> WORKS.

There was not question like "What do you think end users care about?",
therefore I do not see how you came to this conclusion. However, I have
the opinion that we need high quality tools to build high quality
packages. Otherwise we will make more mistakes or have less time to
focus on the tasks that need human intervention.

> On top of this more and more decisions in Fedora seems are made in less and
> less transparent and well technically justified way.

Which decisions are you referring to?

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

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

[Till Maas]

On Tue, Jun 05, 2018 at 08:08:00AM -0700, Adam Williamson wrote:

> I don't know, but it seems worth considering, and my basic point here
> is this is something the Change owner should be responsible for
> figuring out: making at least a reasonable effort to evaluate which
> important (particularly release-critical) software and workflows will
> be affected by the change and proposing plans for testing them. "we
> should check curl behaves as expected" just doesn't really cut it as a
> test plan.

Should we add a QA review step to the change process to address this?
IMHO we cannot expect Change owners to know this or have the same eye
for detail as quality engineers have, therefore the best approach is to
provide them guidance. Or can we assume that the open discussion here
where this can be pointed out is enough?

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

Re: F29 System Wide Change: Hide the grub menu

[Till Maas]

Hi,

On Mon, Jun 04, 2018 at 05:09:46PM +0200, Vít Ondruch wrote:

> Talking from my experience running Rawhide on two my laptops for ~5
> years, I really don't remember where I would really need to use older
> kernel. If I had to, it was probably due to something like audio issues
> with my docking station and that is hardly the situation you describe.

for other people working audio can be essential, e.g. when doing video
conferences. I remember problems with VGA output problems that were
introduced with a kernel with full FLOSS intel drivers which is also
essential for presentations.

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

Re: F29 System Wide Change: Hide the grub menu

[Till Maas]

Hi,

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

> Example 2: Instructions say "press any key" and for whatever reason
> the GRUB USB keyboard module doesn't actually recognize all keys on an
> extended key keyboard. This wouldn't surprise me one bit because
> Fedora, out of the box, doesn't recognize the keypad on my extended
> key keyboard which also doesn't have a numlock button. And is a
> numlock button something GRUB will recognize as "any key"? What about
> Fn? Caps lock?
> 
> If you say any key it must be literally any key on any keyboard and it
> should always work and bring up the intended menu or it's a lie. And
> it's not OK to lie to users, except under really arduous
> circumstances.

My proposal was for the instructions to recommend pressing a certain key
but still accepting any key in grub, then there is no lie, since "Press
space to enter grub" is still true when other keys allow the same.

> >Also it would be awesome if it was still possible to easily
> > reboot to grub after the kernel took over, e.g. from the harddisk
> > password screen, GDM login screen and Gnome logout dialog. Then you can
> > just make it user-friendly and obvious.
> 
> password screen is a plymouth feature request; from what I'm looking
> at gdm login and gnome logout dialog both have a restart option which
> gets me back to GRUB so I'm not following what different behavior
> you're proposing.

My idea was to not have a short timeout when a user selects "Reboot to
Bootloader" (to be implemented) as restart option, so that user do not
have to fiddle with pressing the right key at the right time when they
already know I want to get to the grub menu. Also when they missed the
right time during boot, plymouth could recognise this, make sure the
grub menu will be shown without a short timeout in the next boot and
reboot.

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

Re: F29 System Wide Change: Hide the grub menu

[Till Maas]

Hi,

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

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

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

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

Re: F29 System Wide Change: Hide the grub menu

[Till Maas]

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

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

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

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

Re: Unified Unison package (again)

[Till Maas]

Hi,

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

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

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

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

Re: Unified Unison package (again)

[Till Maas]

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

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

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

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

Why is a module here better than parallel installable RPMs?

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

Re: Fedora Elections May 2018 - Voting period has started for Council and Mindshare elections

[Till Maas]

Hi,

On Thu, May 31, 2018 at 02:19:48AM +0200, Jan Kurik wrote:

> the Voting period of the currently running Fedora Elections [0] has
> just started. Please vote for your candidates to Council [1] and
> Mindshare [2].
> You can vote till June 6th, 2018 when the voting ends at 23:59:59 UTC.
> 
> On Community blog [3] you can also find interviews with all the
> candidates. Please have a look at it.

Could you maybe add links to the interviews to the nomination pages?
They are linked in the voting app as more information about the vote,
therefore it would be great to find the interviews there. It seems that
that candidate's names also link to the interviews but this is not
clearly visible. I guess a text "Interview" with a link would be more
obvious.

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

Re: NEEDINFO denial of service attack

[Till Maas]

Hi,

On Thu, May 31, 2018 at 10:28:42AM +0100, Richard W.M. Jones wrote:
> 
> https://pagure.io/fesco/issue/1736
> 
> I've had about 100 bugs set to NEEDINFO of me to check if some obscure
> Fedora package is vulnerable to some 1 or 2 year old bug.
> 
> Is this a useful use of anyone's time?

it is hard to tell without examples. Are the packages properly
maintained and up to date? Are the obscure packages your packages? If
not, by were you the target of the NEEDINFO?

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

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

[Till Maas]

On Tue, May 29, 2018 at 05:18:48PM +0100, Tomasz Kłoczko wrote:
> On 29 May 2018 at 15:24, Till Maas  wrote:

> > This is also not a serious security threat.
> >
> 
> And this claim bases on what kind of facts?
> Can you prove this?

Sure, there is no logo or catchy name for it.

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

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

[Till Maas]

Hi,

On Tue, May 29, 2018 at 01:44:00PM +0100, Tomasz Kłoczko wrote:

> Just try to grep across /usr for /usr/local. This is not only about $PATH.
> Many scripts, programs or configuration files have HARDCODED checking
> availability of some resources or executables in /usr/local before start
> use those from /usr.

This is also not a serious security threat.

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

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

[Till Maas]

Hi,

On Tue, May 29, 2018 at 10:19:02AM +0100, Sorin Sbarnea wrote:
> I ended up creating
> https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
> others to improve its description.

awesome, I was about to do the same, therefore I added myself as second
owner to express that I will support this. Do you have an opinion about
what to do with ~/bin, IMHO it should be prioritized, too. I am not sure
if there is a real use case to keep it with lower priority. If there is,
then I will add it to the proposal.

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

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

[Till Maas]

Hi,

On Tue, May 29, 2018 at 10:19:44AM +0100, Tomasz Kłoczko wrote:

> distribution binaries is extremely dangerous, and I'm really surprised that
> no one looks on those already discussed here issues (and few similar or
> related) as SERIOUS SECURITY TREAT to whole distribution.

IIRC enough people explained why these are not serious security threats.

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

Re: Would be possible to add freerdp2 package only for EPEL?

[Till Maas]

On Tue, May 29, 2018 at 10:58:37AM +0200, Marcin Juszkiewicz wrote:

> I thought that this would not be a problem as epel is built on Fedora
> infra which is not same as rhel one.

The problem is that koji needs to know about the RHEL packages to be
able to create buildroots for EPEL. This is were they would conflict.

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

Re: [fesco] Updated FTBFS package policy

[Till Maas]

Hi,

On Mon, May 28, 2018 at 01:53:28PM +0200, Jiri Vanek wrote:

> The second one is pretty strong one. Does it incue system packages too? If
> so, note that it can be hard to adapt some packages to new GCC or (in
> future) new JDK11 in short interval of two mass rebuilds.

The short interval is usually six months (not that short) and I guess if
an important package cannot be rebuilt because of a new GCC or JDK, we
need a compatibility package to make sure the package can still be
built.

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

Re: Would be possible to add freerdp2 package only for EPEL?

[Till Maas]

Hi,
On Mon, May 28, 2018 at 01:22:46PM +0200, Ondrej Holy wrote:

> Unfortunately, EPEL branch for freerdp can't be simply created due to
> package name conflict. Would be possible to add freerdp2 package only for
> EPEL?

yes, just mention this in the review and retire the master branch
directly after import, for reference, this is described in the EPEL FAQ:
https://fedoraproject.org/wiki/EPEL/FAQ#Is_it_possible_to_get_a_package_only_into_EPEL_and_not_Fedora.3F

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

Re: [fesco] Updated FTBFS package policy

[Till Maas]

Hi Andrew,

On Sun, May 27, 2018 at 06:47:09AM -0700, Andrew Lutomirski wrote:

> Can you check that whatever scripts are doing this work are filing
> sensible bug reports?  I got this:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1582774
> 
> which has totally wrong text.  This isn't a Fedora 28 FTBFS -- it's a
> Fedora 29 FTBFS.

Everything that was not rebuilt after 2018-02-06 01:20:06.00 is
considered a Fedora 28 FTBFS because it was the cutoff date for the
Fedora 28 mass rebuild. However, the mass rebuild failed to start a
build for all packages and it seems that fish was not rebuilt in the
mass rebuild according to
https://koji.fedoraproject.org/koji/packageinfo?packageID=1732

To get some information about the status of the packages I submitted a
new build of them. Since Fedora 28 is now released/Rawhide is now Fedora
29, the builds target Fedora 29. The easiest way to avoid this is to
make sure that there is a successful build after the time specified
above and it seems that you created such a build.

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

Re: [fesco] Updated FTBFS package policy

[Till Maas]

Hi,

On Sat, May 26, 2018 at 04:27:15PM +0100, Sérgio Basto wrote:
> On Fri, 2018-05-25 at 15:46 +, Zbigniew Jędrzejewski-Szmek wrote:
> > Fedora package maintainers,
> > 
> > FESCo approved an updated policy for packages which fail to build
> > from
> > source during mass rebuilds (FTBFS) [1].
> 
> Please list all candidates packages to be retired , last time Till
> check was about 2000 IIRC 

There is no final list yet. I am currently rebuilding several packages
to ensure that there is a bug report for each package. The most accurate
list can be found here:
https://bugzilla.redhat.com/showdependencytree.cgi?id=1555378_resolved=1

During the F28 rebuild, the process failed to trigger a rebuild for a
lot of packages. I rebuilt a lot of them a while ago but I missed some,
too (I guess all packages that were rebuilt after the F26 mass rebuild
but not for F28). I am rebuilding them now, too. Also I will rebuild
packages for which a bug report is missing or lacks the log files.

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

Re: herbstluftwm

[Till Maas]

Hi Silvia,

just a short follow up, are you using herbstluftwm? Usually it makes sense to 
package what you use to be familiar with the package. Also it would be great if 
you create pull requests with your proposed changes to herbstluftwm.

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

Re: herbstluftwm

[Till Maas]

Am 26. Mai 2018 10:54:37 MESZ schrieb Alexander Ploumistos 
:
>Hi Silvia,
>
>On Sat, May 26, 2018 at 10:07 AM Silvia Sánchez 
>wrote:
>> Hi,
>
>> Mastaiza, would you be so kind to sponsor me?  I'll be glad to
>maintain
>your package, I like it and it's a shame it's going to be orphaned.
>
>herbstluftwm used to be maintained by Christopher Meng (cicku).
>Mastaiza is not one of our sponsors, nor is he a member of the packager
>group, so he can not sponsor you.
>The wiki page that Michael Cronenworth mentioned contains everything
>you
>need to know, as well as an overwhelming number of links to other wiki
>pages, with even more information relevant to becoming a packager, e.g.
>http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
>
>While you're looking for a sponsor it would be a good idea to update
>herbstluftwm to v0.7 (in COPR, or whatever works for you), bring its
>spec
>file up to speed with the latest guidelines and conduct a few informal
>package reviews.
>
>> Kind regards,
>> Silvia
>> FAS:  Lailah
>
>One last little thing, your FAS name is spelled "lailah", with a
>lowercase
>l. Not that people won't be able to find you, just saying.

Hi Silvia,
 
I will sponsor you if you do what Alexander suggested and do a few preliminary 
reviews.

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

orphaned aircrack-ng

[Till Maas]

Hi,

I just orphaned aircrack-ng, it needs more love than I am able to give
it at the moment. It would be great to keep it in the distribution,
though. Unfortunately there are some open bugs but since upstream just
moved to GitHub there is at least hope that there will be bugfixes
eventually.

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

Rebuilding a lot of packages that fail to build from source (FTBFS)

[Till Maas]

Hi,

I am currently rebuilding about 1000 packages in Rawhide that were not
properly rebuilt in the last mass rebuild or failed to build. So if you
wonder why I rebuilt your package, this is why. Since it also seems that
the bug reports for the last mass rebuild are lacking the log files, I
might rebuild some more packages to get the log files when I proceed to
file proper bug reports. Afterwards we will re-start a process to
clean-up long time FTBFS packages. The progress is tracked in the
following FESCo issue: https://pagure.io/fesco/issue/1877

There are currently 797 bugs open for the last mass rebuild (this number
will go up), please fix your packages at your earliest convenience:
https://bugzilla.redhat.com/showdependencytree.cgi?id=1555378_resolved=1

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

Summary/Minutes from last FESCo Meeting (2018-03-23)

[Till Maas]

 * bowlofeggs will mark it as a final blocker
  * bowlofeggs will make sure a change is written NO MATTER WHAT HAPPENS
  * bowlofeggs will ask them again for a change page and write one for
himself if the maintainers do not provide one
* msekleta
  * msekleta will test pppoe with a VM setup
* sgallagh
  * sgallagh will chair instead of zbyszek
* zbyszek
  * zbyszek to reach out to the change owner
  * zbyszek to generate a wiki page with arguments and considerations,
ask for feedback
  * zbyszek will chair next meeting
  * sgallagh will chair instead of zbyszek
* **UNASSIGNED**
  * till write use his PP powers to merge tcp wrapper patches




People Present (lines said)
---
* bowlofeggs (138)
* tyll (117)
* zbyszek (88)
* sgallagh (74)
* nirik (55)
* jsmith (32)
* dgilmore (21)
* zodbot (20)
* maxamillion (15)
* puiterwijk (14)
* msekleta (10)
* kparal (7)
* nb (1)
* jwb (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


15:00:34  #startmeeting FESCO (2018-03-23)
15:00:34  Meeting started Fri Mar 23 15:00:34 2018 UTC.  The chair is 
tyll. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:34  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
15:00:34  The meeting name has been set to 'fesco_(2018-03-23)'
15:00:37  .hello2
15:00:38  zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 
<zbys...@in.waw.pl>
15:00:38  .hello2
15:00:41  bowlofeggs: bowlofeggs 'Randy Barlow' <rbar...@redhat.com>
15:01:01  :D axamillion dgilmore nirik jsmith sgallagh bowlofeggs tyll 
jwb zbyszek
15:01:10  .hello2
15:01:11  jsmith: jsmith 'Jared Smith' <jsmith.fed...@gmail.com>
15:01:11  #chair maxamillion dgilmore nirik jsmith sgallagh bowlofeggs 
tyll jwb zbyszek
15:01:11  Current chairs: bowlofeggs dgilmore jsmith jwb maxamillion 
nirik sgallagh tyll zbyszek
15:01:12  morning
15:01:18  #meetingname fesco
15:01:18  The meeting name has been set to 'fesco'
15:01:25  #topic init process
15:01:26  .hello2
15:01:27  sgallagh: sgallagh 'Stephen Gallagher' <sgall...@redhat.com>
15:01:31  .hello till
15:01:32  tyll: till 'Till Maas' <opensou...@till.name>
15:02:33  I count 6 members, so we have quorum
15:02:52  hi
15:03:07  now 7 :-)
15:03:12  w00t!
15:03:15  16:01:19  The meeting name has been set to 'fesco' A 
status (<100% completed)
15:03:19  #topic #1861 F28 Changes not in ON_QA status (<100% completed)
15:03:36  .fesco 1861
15:03:38  tyll: Issue #1861: F28 Changes not in ON_QA status (<100% 
completed) - fesco - Pagure - https://pagure.io/fesco/issue/1861
15:03:52  Can we discuss them one by one?
15:03:54  there are only issues from last meeting
15:03:58  #topic Kerberos in Python modernization
15:04:02  
https://fedoraproject.org/wiki/Changes/kerberos-in-python-modernization
15:04:05  https://bugzilla.redhat.com/show_bug.cgi?id=1537249
15:04:09  zbyszek: sure
15:04:27  We were supposed to ask the maintainer to update the page, 
but nothing happened there
15:04:32  AGREED: (+1:6,+0:0,-1:0) - ask change owner to update change 
with what will be shipped in f28 and file any later changes in an F29 change 
request
15:04:43  yes, this was the last item ^
15:04:48  last decission
15:04:56  does someone volunteer to ask this time?
15:05:01  I will.
15:05:04  Did someone actually reach out to the change owner?
15:05:14  Thanks zbyszek
15:05:15  #action zbyszek to reach out to the change owner
15:05:53  #info nothing happened since last meeting, will discuss it 
again next meeting
15:05:59  any objections?
15:06:02  +1
15:06:12  ack
15:06:16  ACK
15:06:23  ack
15:06:45  ack
15:07:20  ok, next subitem
15:07:25  #topic Add-On Modularity
15:07:29  https://fedoraproject.org/wiki/Changes/F28AddonModularity
15:07:32  https://bugzilla.redhat.com/show_bug.cgi?id=1537253
15:07:50  sgallagh?
15:07:52  bodhi is now ready for f28 modularity afaik
15:07:56  last meeting: AGREED: The critieria posted in comments 6 and 7 
at https://bugzilla.redhat.com/show_bug.cgi?id=1537253 are required for 
modularity (+8, 0, -0)
15:07:57  @sgallagh will inform the QA team
15:07:58  I think we are in a state where everything can at least be 
tested. ;)
15:08:04  From what (little) I understand, the modularity stuff is 
coming along and pretty much ready to go
15:08:14  Yes, we're in much better shape
15:09:01  As far as I know, we are meeting all of the blocking 
criteria we established
15:09:13  I'm going to continue to put it through it's paces before 
Go/No-Go next week
15:09:29  Cool.
15:09:45  should the ticket be moved to ON_QA then?
15:09:55  It is already.
15:09:56  bowlofeggs: it already is
15:10:16  ah then we don't really need to discuss it here
15:10:27  since the fesco ticket is about tickets not on ON_QA :)
15:10:31  Yeah, seems to be on track for beta.
15:11:33  +1 to moving on
15:12:09  ok, next item:
15:12:11  #topic Replace glibc's libcrypt with libxcrypt
15:12:16  
https://fedoraproject.org/wiki/Changes/Replace_glibc

Re: josm orphaned, or why are we packaging

[Till Maas]

On Thu, Mar 22, 2018 at 01:49:27PM -0400, Przemek Klosowski wrote:

> 1. ELF binaries
> 2. binary run-time loadable libraries
> 3. script files for scripting language environments (java programs
>could be arguably placed here)
> 4. scripting language libraries
> 5. java applets running in the browser
> 6. javascript running in the browser
> 
> Clearly, we want to package 1. and 2., and we aren't going to start
> packaging 6; there's a big discussion as to what's the right approach for 3
> and 4 (npm, conda, cargo, etc).

Actually 6. is also packaged for web applications that we package. Not
sure if there are still stand-alone packages for jquery but the code is
at least bundled in other packages.

> One way of looking at it is that packaging provides an assurance that the
> software we're running is the software we think you're running, as opposed
> to downloading random binaries and scripts from the internet (curl |
> /bin/sh). In this way of thinking, software downloaded from secure
> (TLS/https) connections to trusted sites could  be considered as good as
> packaged---we're doing it to javascript so why not java and other things.

One big difference is that Javascript is sandboxed in the browser. Also
download code just via https is not as good as it being packaged. With
packages you can also rollback to older versions or decide when to
upgrade. Also signed packages make sure that everyone gets the same
thing because there is only one signed RPM for each NVR which also
allows for QA. See for example the NPM bug:

http://www.zdnet.com/article/show-stopping-bug-appears-in-npm-node-js-package-manager/

Also there have been instances where upstream downloads were compromised
in the past.

> The .jnlp file that provides JOSM is essentially an XML file which starts
> the java machinery running the OSM-provided java application--I can see how
> people could argue that it's no different from maps.google.com starting a
> javascript mapping application in your browser.

Google maps is not FLOSS and a stand-alone application has still
advantages over a web application. So using a java web start application
might be as good as using a javascript web app, but a stand-alone
application can still be better. For example, is it possible to add a
java web start application to the gnome favorites? I guess it is only
possible with manually writing a .desktop file.

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

josm orphaned

[Till Maas]

Hi

I orphaned josm (https://src.fedoraproject.org/rpms/josm), the java
openstreetmap editor on request by the original maintainer. Please adopt
it. It needs to be updated regularly to follow the current openstreetmap
guidelines, currently it is outdated (also in EPEL).

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

Schedule for Friday's FESCo Meeting (2018-03-23)

[Till Maas]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 15:00UTC in #fedora-meeting on
irc.freenode.net.

To convert UTC to your local time, take a look at
  https://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2018-03-23 15:00 UTC'


Links to all issues below can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Followups =

#topic #1861 F28 Changes not in ON_QA status (<100% completed)
.fesco 1861
https://pagure.io/fesco/issue/1861

#topic #1820 Adjust/Drop/Document batched updates policy
.fesco 1820
https://pagure.io/fesco/issue/1820

#topic #1845 389-ds-base and freeipa on 32 bit arches
.fesco 1845
https://pagure.io/fesco/issue/1845

#topic #1776 F28 System Wide Change: Deprecate TCP wrappers
.fesco 1776
https://pagure.io/fesco/issue/1776

= New business =

#topic #1865 Please orphan package "josm" by "cquad"
.fesco 1865
https://pagure.io/fesco/issue/1865


= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Till Maas]

On Sat, Feb 10, 2018 at 10:25:48PM +0100, David Sommerseth wrote:

> I personally find it abusing shared resources throwing builds at it which has
> not been tested first.  So I prefer to do local mockbuilds first, simply to
> lessen the load on shared resources.  I'm not saying I haven't tossed failing
> builds at koji, that has happened too.  But I generally try to avoid that as
> much as I can.

koji has enough ressources to allow for test builds. You can actually to
test-only builds (so-called stretch builds). IMHO the scarcer resource
is maintainer time, therefore I am all for using as much shared
resources as possible if it frees time for maintainers. See also:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

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

Re: Orphaned packages seeking new point of contact

[Till Maas]

On Mon, Feb 05, 2018 at 07:42:45AM -0500, Josh Boyer wrote:
> On Fri, Feb 2, 2018 at 3:22 PM, Michael Schwendt  wrote:
> > On Fri, 2 Feb 2018 10:32:33 -0800, Kevin Fenzi wrote:
> >
> >> rpms/gqview

> > It is unmaintained for over 10 years.
> >
> > It has been forked into Geeqie (package "geeqie") roughly 10 years
> > ago, and Geeqie at least has seen several releases since then.
> 
> Perhaps just take gqview and retire it then?

Actually Michael retired in 2010 for Fedora. jcapik maintained it in
EPEL 6 according to pkgdb [0]. This inofrmation does not seem to have been
migrated afaics:

https://pagure.io/releng/fedora-scm-requests/raw/master/f/rpms/gqview
should say that jcapik receives the EPEL but reports but it does not
AFAIU.

[0] https://admin.fedoraproject.org/pkgdb/package/rpms/gqview/

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