Re: orphaning bleachbit

2019-12-21 Thread John M. Harris Jr 
On Sunday, May 19, 2019 2:05:46 AM MST Silvia Sánchez wrote:
> Hello,
> 
> Yes, I know Python 2 will be soon removed, but I can't just let Bleachbit
> die.  It's too useful for that.
> Finding a sponsor seems to be the hard bit.  I've been looking for one for
> ages.
> Thanks for the answer.
> 
> Kind regards,
> Silvia
> FAS:  Lailah

Unfortunately, this package will eventually be hurt by this new FESCo policy 
to remove Python2. It is unfortunate, but cannot really be avoided. If it 
doesn't get a FESCo exception (and FESCo has denied several exceptions, 
regardless of the package actually having a maintainer), it will be removed 
without consent from you or another maintainer.


-- 
John M. Harris, Jr.
Splentity

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

Re: Removing a commit

2019-12-21 Thread Nico Kadel-Garcia 
On Sat, Dec 21, 2019 at 5:06 PM Kevin Kofler  wrote:
>
> Nico Kadel-Garcia wrote:
> > It is *possible* to branch from right before the commit, and put
> > *that* in your branch or your local repo to work with. It's also
> > possible to replace an upstream git repo, entirely, with a repo that
> > does not have the commit.
>
> The Fedora dist-git git hooks won't allow such a thing (a "force push").
>
> Kevin Kofler

I believe you! This is a wise precaution for a reference repository.
I've had people do a "force push" for various reasons and cause
genuine adventures later. Conversely, I've had upstream repos that
accidentally had passwords or DVD files stored in them and needed to
be forcibly cleared of inappropriate content.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

2019-12-21 Thread Tomasz Kłoczko 
On Sat, 21 Dec 2019 at 00:37, Neal Gompa  wrote:
[..]

> I believe it's also used by the %cmake and %meson macros.


Yep.
Look on the output of the “rpm -E %cmake” and you will find that to switch
to other C and C++ compilers all what you need to do is redefine %__cc and
%__cxx macros,
The same is with %configure and %meson,

In other words you can switch NOW from non-root account to other compiler
without execution update-alternatives from root.

In other words this proposal is pointless.

kloczek
-- 
-- 
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH
*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Removing a commit

2019-12-21 Thread Kevin Kofler 
Nico Kadel-Garcia wrote:
> It is *possible* to branch from right before the commit, and put
> *that* in your branch or your local repo to work with. It's also
> possible to replace an upstream git repo, entirely, with a repo that
> does not have the commit.

The Fedora dist-git git hooks won't allow such a thing (a "force push").

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

Re: Removing a commit

2019-12-21 Thread Nico Kadel-Garcia 
On Sat, Dec 21, 2019 at 3:20 PM Fabio Valentini  wrote:
>
> On Sat, Dec 21, 2019 at 9:11 PM Antonio Trande  wrote:
> >
> > Hi all.
> >
> > Please, can you help me to remove this last commit on EPEL7 branch?
> >
> > https://src.fedoraproject.org/rpms/petsc4py/c/e47fbb3ef419b7be939108c2b1deff3f105bfdbc?branch=epel7
> >
> > (I wish top return to the 3.11.0 release of petsc4py)
>
> git commits cannot be removed from dist-git.
> If you have not built this commit for EPEL7, then reverting the
> unwanted commits and pushing the result should do what you want?
> (I see that this is a merge commit, and I don't know how smart git is
> with reverting merge commits. You'll have to try to see it, I guess.)
>
> Fabio

It is *possible* to branch from right before the commit, and put
*that* in your branch or your local repo to work with. It's also
possible to replace an upstream git repo, entirely, with a repo that
does not have the commit. This is the feature that CVS had, and
Subversion absolutely refuses to support, and it can be *done* with
git but leaves split brain with any clones that contain that
commit.It's quite dangerous to do. A "revert" command is normally
much, much, much safer.
___
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: Removing a commit

2019-12-21 Thread Antonio Trande 

On 21/12/19 21:50, Fabio Valentini wrote:
>>
>> Yes,
>> https://src.fedoraproject.org/rpms/petsc4py/c/cf25d6d376fc95034decec02c2e1501f97ae4955?branch=epel7
> 
> It failed because it can't tell which branch to restore the state to,
> since you're reverting a merge commit.
> 
> "git revert HEAD -m 1" does what you want, I think.
> "-m 1" tells git to restore to the state of the epel7 branch, not the
> master branch, which was merged into epel7.
> 
> Fabio

It's working..
Thank you very much.

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Removing a commit

2019-12-21 Thread Fabio Valentini 
On Sat, Dec 21, 2019 at 9:44 PM Antonio Trande  wrote:
>
>
>
> On 21/12/19 21:38, Fabio Valentini wrote:
> > On Sat, Dec 21, 2019 at 9:30 PM Antonio Trande  
> > wrote:
> >>
> >> On 21/12/19 21:19, Fabio Valentini wrote:
> >>> On Sat, Dec 21, 2019 at 9:11 PM Antonio Trande  
> >>> wrote:
> 
>  Hi all.
> 
>  Please, can you help me to remove this last commit on EPEL7 branch?
> 
>  https://src.fedoraproject.org/rpms/petsc4py/c/e47fbb3ef419b7be939108c2b1deff3f105bfdbc?branch=epel7
> 
>  (I wish top return to the 3.11.0 release of petsc4py)
> >>>
> >>> git commits cannot be removed from dist-git.
> >>> If you have not built this commit for EPEL7, then reverting the
> >>> unwanted commits and pushing the result should do what you want?
> >>> (I see that this is a merge commit, and I don't know how smart git is
> >>> with reverting merge commits. You'll have to try to see it, I guess.)
> >>>
> >>> Fabio
> >>>
> >>
> >> Hi Fabio.
> >>
> >> $ fedpkg switch-branch epel7
> >> Branch 'epel7' set up to track remote branch 'epel7' from 'origin'.
> >
> > 
> >
> >> $ git reset --hard cf25d6d376fc95034decec02c2e1501f97ae4955
> >> HEAD is now at cf25d6d Rebuild for PETSc-3.11.3
> >>
> >> $ git commit -am "Undo latest commit"
> >> On branch epel7
> >> Your branch is behind 'origin/epel7' by 6 commits, and can be
> >> fast-forwarded.
> >>   (use "git pull" to update your local branch)
> >>
> >> nothing to commit, working tree clean
> >
> > That's why I wrote "revert" and not "reset".
>
> Because it failed:
>
> $ fedpkg switch-branch epel7
> Branch 'epel7' set up to track remote branch 'epel7' from 'origin'.
> $ git revert cf25d6d376fc95034decec02c2e1501f97ae4955
> error: commit cf25d6d376fc95034decec02c2e1501f97ae4955 is a merge but no
> -m option was given.
> fatal: revert failed
>
> >
> > Which commit is the one you want to restore the epel7 branch to? cf25d6d?
> >
>
> Yes,
> https://src.fedoraproject.org/rpms/petsc4py/c/cf25d6d376fc95034decec02c2e1501f97ae4955?branch=epel7

It failed because it can't tell which branch to restore the state to,
since you're reverting a merge commit.

"git revert HEAD -m 1" does what you want, I think.
"-m 1" tells git to restore to the state of the epel7 branch, not the
master branch, which was merged into epel7.

Fabio

> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x7B30EE04E576AA84
> GPG key server: https://keys.openpgp.org/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Removing a commit

2019-12-21 Thread Antonio Trande 


On 21/12/19 21:38, Fabio Valentini wrote:
> On Sat, Dec 21, 2019 at 9:30 PM Antonio Trande  wrote:
>>
>> On 21/12/19 21:19, Fabio Valentini wrote:
>>> On Sat, Dec 21, 2019 at 9:11 PM Antonio Trande  
>>> wrote:

 Hi all.

 Please, can you help me to remove this last commit on EPEL7 branch?

 https://src.fedoraproject.org/rpms/petsc4py/c/e47fbb3ef419b7be939108c2b1deff3f105bfdbc?branch=epel7

 (I wish top return to the 3.11.0 release of petsc4py)
>>>
>>> git commits cannot be removed from dist-git.
>>> If you have not built this commit for EPEL7, then reverting the
>>> unwanted commits and pushing the result should do what you want?
>>> (I see that this is a merge commit, and I don't know how smart git is
>>> with reverting merge commits. You'll have to try to see it, I guess.)
>>>
>>> Fabio
>>>
>>
>> Hi Fabio.
>>
>> $ fedpkg switch-branch epel7
>> Branch 'epel7' set up to track remote branch 'epel7' from 'origin'.
> 
> 
> 
>> $ git reset --hard cf25d6d376fc95034decec02c2e1501f97ae4955
>> HEAD is now at cf25d6d Rebuild for PETSc-3.11.3
>>
>> $ git commit -am "Undo latest commit"
>> On branch epel7
>> Your branch is behind 'origin/epel7' by 6 commits, and can be
>> fast-forwarded.
>>   (use "git pull" to update your local branch)
>>
>> nothing to commit, working tree clean
> 
> That's why I wrote "revert" and not "reset".

Because it failed:

$ fedpkg switch-branch epel7
Branch 'epel7' set up to track remote branch 'epel7' from 'origin'.
$ git revert cf25d6d376fc95034decec02c2e1501f97ae4955
error: commit cf25d6d376fc95034decec02c2e1501f97ae4955 is a merge but no
-m option was given.
fatal: revert failed

> 
> Which commit is the one you want to restore the epel7 branch to? cf25d6d?
> 

Yes,
https://src.fedoraproject.org/rpms/petsc4py/c/cf25d6d376fc95034decec02c2e1501f97ae4955?branch=epel7


-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Removing a commit

2019-12-21 Thread Fabio Valentini 
On Sat, Dec 21, 2019 at 9:30 PM Antonio Trande  wrote:
>
> On 21/12/19 21:19, Fabio Valentini wrote:
> > On Sat, Dec 21, 2019 at 9:11 PM Antonio Trande  
> > wrote:
> >>
> >> Hi all.
> >>
> >> Please, can you help me to remove this last commit on EPEL7 branch?
> >>
> >> https://src.fedoraproject.org/rpms/petsc4py/c/e47fbb3ef419b7be939108c2b1deff3f105bfdbc?branch=epel7
> >>
> >> (I wish top return to the 3.11.0 release of petsc4py)
> >
> > git commits cannot be removed from dist-git.
> > If you have not built this commit for EPEL7, then reverting the
> > unwanted commits and pushing the result should do what you want?
> > (I see that this is a merge commit, and I don't know how smart git is
> > with reverting merge commits. You'll have to try to see it, I guess.)
> >
> > Fabio
> >
>
> Hi Fabio.
>
> $ fedpkg switch-branch epel7
> Branch 'epel7' set up to track remote branch 'epel7' from 'origin'.



> $ git reset --hard cf25d6d376fc95034decec02c2e1501f97ae4955
> HEAD is now at cf25d6d Rebuild for PETSc-3.11.3
>
> $ git commit -am "Undo latest commit"
> On branch epel7
> Your branch is behind 'origin/epel7' by 6 commits, and can be
> fast-forwarded.
>   (use "git pull" to update your local branch)
>
> nothing to commit, working tree clean

That's why I wrote "revert" and not "reset".

Which commit is the one you want to restore the epel7 branch to? cf25d6d?

Fabio

> $ ll
> total 36
> petsc4py-3.11.0-bug125.patch
> petsc4py-mpich_set_dir.patch
> petsc4py-openmpi_set_dir.patch
> petsc4py.spec
> 21.25 sources
>
> $ git push
> To ssh://pkgs.fedoraproject.org/rpms/petsc4py
>  ! [rejected]epel7 -> epel7 (non-fast-forward)
> error: failed to push some refs to
> 'ssh://sagit...@pkgs.fedoraproject.org/rpms/petsc4py'
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x7B30EE04E576AA84
> GPG key server: https://keys.openpgp.org/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Removing a commit

2019-12-21 Thread Antonio Trande 

On 21/12/19 21:19, Fabio Valentini wrote:
> On Sat, Dec 21, 2019 at 9:11 PM Antonio Trande  wrote:
>>
>> Hi all.
>>
>> Please, can you help me to remove this last commit on EPEL7 branch?
>>
>> https://src.fedoraproject.org/rpms/petsc4py/c/e47fbb3ef419b7be939108c2b1deff3f105bfdbc?branch=epel7
>>
>> (I wish top return to the 3.11.0 release of petsc4py)
> 
> git commits cannot be removed from dist-git.
> If you have not built this commit for EPEL7, then reverting the
> unwanted commits and pushing the result should do what you want?
> (I see that this is a merge commit, and I don't know how smart git is
> with reverting merge commits. You'll have to try to see it, I guess.)
> 
> Fabio
> 

Hi Fabio.

$ fedpkg switch-branch epel7
Branch 'epel7' set up to track remote branch 'epel7' from 'origin'.

$ git reset --hard cf25d6d376fc95034decec02c2e1501f97ae4955
HEAD is now at cf25d6d Rebuild for PETSc-3.11.3

$ git commit -am "Undo latest commit"
On branch epel7
Your branch is behind 'origin/epel7' by 6 commits, and can be
fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean

$ ll
total 36
petsc4py-3.11.0-bug125.patch
petsc4py-mpich_set_dir.patch
petsc4py-openmpi_set_dir.patch
petsc4py.spec
21.25 sources

$ git push
To ssh://pkgs.fedoraproject.org/rpms/petsc4py
 ! [rejected]epel7 -> epel7 (non-fast-forward)
error: failed to push some refs to
'ssh://sagit...@pkgs.fedoraproject.org/rpms/petsc4py'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.


-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Removing a commit

2019-12-21 Thread Fabio Valentini 
On Sat, Dec 21, 2019 at 9:11 PM Antonio Trande  wrote:
>
> Hi all.
>
> Please, can you help me to remove this last commit on EPEL7 branch?
>
> https://src.fedoraproject.org/rpms/petsc4py/c/e47fbb3ef419b7be939108c2b1deff3f105bfdbc?branch=epel7
>
> (I wish top return to the 3.11.0 release of petsc4py)

git commits cannot be removed from dist-git.
If you have not built this commit for EPEL7, then reverting the
unwanted commits and pushing the result should do what you want?
(I see that this is a merge commit, and I don't know how smart git is
with reverting merge commits. You'll have to try to see it, I guess.)

Fabio

> Regards.
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x7B30EE04E576AA84
> GPG key server: https://keys.openpgp.org/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Removing a commit

2019-12-21 Thread Antonio Trande 
Hi all.

Please, can you help me to remove this last commit on EPEL7 branch?

https://src.fedoraproject.org/rpms/petsc4py/c/e47fbb3ef419b7be939108c2b1deff3f105bfdbc?branch=epel7

(I wish top return to the 3.11.0 release of petsc4py)

Regards.
-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: orphaning bleachbit

2019-12-21 Thread alciregi 
On Sat, 2019-12-21 at 20:50 +0300, Silvia Sánchez wrote:
> 
> Hi Alessio,
> 
> Yes, I am.

We could comaintain it, if you like, even if I'm not an expert
packager.
Bleachbit was retired from F31 [1]
Another point is that bleachbit version 3.0 still requires python2.
So, since "the top priority [of bleachbit developers] is to update
Python 2.7 to Python 3" [2], it make sense to wait the new version
before proceeding to unretire it and submit a new package, even if
there is a python3 branch on github [3]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1737902
[2] https://www.bleachbit.org/news/bleachbit-30
[3] https://github.com/bleachbit/bleachbit/tree/py3
___
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: systemd 244-rc1

2019-12-21 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Nov 22, 2019 at 04:17:03PM +, Zbigniew Jędrzejewski-Szmek wrote:
> This version has support for disabling watchdogs at configuration time
> for services bundled with systemd. I want to do that in Fedora, because almost
> all "crash" reports that we get are about the watchdog firing on resource
> starvation, which is not good, but having the watchdog terminate the process
> has very little benefit for the users, and spams bugzilla with useless 
> reports.
> I didn't actually disable the watchdogs yet, but I'll plan to do it on Monday
> if the version that was built now seems OK.

Systemd with service watchdogs disabled is now building in rawhide.

Zbyszek

> For full NEWS, see https://github.com/systemd/systemd/blob/master/NEWS#L3.
___
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: orphaning bleachbit

2019-12-21 Thread Silvia Sánchez 
Hi Alessio,

Yes, I am.





On Sat, 21 Dec 2019 at 20:33, Alessio Ciregia  wrote:

> Hello Lailah, are you still interested in maintaining that?
>
> A.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: orphaning bleachbit

2019-12-21 Thread Alessio Ciregia 
Hello Lailah, are you still interested in maintaining that?

A.
___
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: devel Digest, Vol 190, Issue 186

2019-12-21 Thread Jeff Law 
On Sat, 2019-12-21 at 10:52 -0500, Josh Boyer wrote:
> On Thu, Dec 19, 2019 at 5:48 PM Jeff Law  wrote:
> > On Thu, 2019-12-19 at 16:24 -0600, Neal Gompa wrote:
> > > On Thu, Dec 19, 2019 at 4:14 PM Jeff Law  wrote:
> > > > On Thu, 2019-12-19 at 21:56 +, devel-
> > > > requ...@lists.fedoraproject.org wrote:
> > > > 
> > > > Neal,
> > > > 
> > > > 
> > > > > I'm generally happy with this idea. I'm one of the maintainers of
> > > > > rpm-config-SUSE (the equivalent of redhat-rpm-config for SUSE
> > > > > distributions) and I somewhat saw the development of this feature
> > > > > across rpm, rpm-config-SUSE, and the implementation in openSUSE
> > > > > Tumbleweed.
> > > > Understood.  FWIW, I work closely with Martin L, Martin J, Jan and
> > > > Richi @ SuSE.  Martin L and I in particular coordinate on mass build
> > > > testing & related failure analysis and bugfixing.
> > > > 
> > > 
> > > Martin Liška is the one I've primarily interfaced with throughout the
> > > implementation.
> > > 
> > > I don't know if you know about this, but there's a tracker bug for
> > > LTO-related failures: https://bugzilla.opensuse.org/1133084
> > I am aware of it and have referenced it several times in my own work.
> > 
> > > We should probably make sure this is cross-referenced as LTO is
> > > implemented in Fedora.
> > Sure.  That's easy enough to do.  Some of the information is dated, but
> > there still useful nuggets in there.
> > 
> > They punted lots of stuff though.  In particular they punted the
> > configure problem and middle-end issued diagnostics, which was terribly
> > unfortunate.
> > 
> > > > > However, the implementation of LTO in openSUSE caused major problems
> > > > > for "weaker" architectures like ARM and RISC-V. In Fedora, ARM is
> > > > > co-primary with the rest of the architectures (ARM is allowed to be
> > > > > broken in openSUSE from time to time). The major problems we
> > > > > encountered was increased miscompilation errors and timeouts due to
> > > > > builds taking even longer with LTO straining ARM build environments.
> > > > Yes.  The 32bit architectures in particular are expected to be slightly
> > > > problematical due to the limited address space.  Even with Jan's work
> > > > in this area, I expect things like firefox to simply be too big to
> > > > compile/link using LTO on the 32bit platforms.
> > > > 
> > > > When I discussed this with Martin L and one of the Ubuntu engineers
> > > > (Matthias) back in Sept, the general plan we agreed on was to first get
> > > > the Fedora test builds in reasonable shape on x86_64 that we could use
> > > > as a baseline (and we're just about there).  Then do an i686 build for
> > > > comparison purposes.
> > > > 
> > > > For packages we find problematical on the 32bit platforms, we'll be
> > > > able to trivially opt-out of LTO for that package on those 32bit
> > > > platforms.  It's a one-liner in the .spec file.
> > > > 
> > > > 
> > > 
> > > Are we going to use the same %_lto_cflags mechanism that was
> > > implemented in openSUSE, or are we going to do something different?
> > Ideally the same.  I don't own redhat-rpm-config, but certainly my
> > preference is use the same mechanisms.
> > 
> > > 
> > > I'd like to see at *least* AArch64 spun to see how well this goes. I'm
> > > reasonably confident that POWER8+ would be fine, since we don't have
> > > ppc64be anymore (and I *know* that one was broken, since I reported it
> > > years ago: https://bugzilla.redhat.com/1515934).
> > Obviously aarch64 will be built and any issues resolved as is the case
> > with other architectures.  We do this every spring cycle with the
> > introduction of a major GCC release and we work closely with the GCC
> > engineers at ARM and IBM along the way.
> > 
> > Building 9000 packages 3X each (gcc-10+LTO, gcc-10, gcc-9 baseline)
> > takes significant hardware.  If there's hardware I can use (and you
> > should be thinking on the order of dozens of dedicated machines), then
> > I'm happy to use them.  I mentioned ppc64le simply because I can get
> > access to a goodly number of them.
> 
> Is there a reason you couldn't use aarch64 AWS instances?
I've actually applied for aws credits which could be used for this. 
THe instances in the free tier are too small to really be useful.

jeff
> 
___
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: devel Digest, Vol 190, Issue 186

2019-12-21 Thread Josh Boyer 
On Thu, Dec 19, 2019 at 5:48 PM Jeff Law  wrote:
>
> On Thu, 2019-12-19 at 16:24 -0600, Neal Gompa wrote:
> > On Thu, Dec 19, 2019 at 4:14 PM Jeff Law  wrote:
> > > On Thu, 2019-12-19 at 21:56 +, devel-
> > > requ...@lists.fedoraproject.org wrote:
> > >
> > > Neal,
> > >
> > >
> > > > I'm generally happy with this idea. I'm one of the maintainers of
> > > > rpm-config-SUSE (the equivalent of redhat-rpm-config for SUSE
> > > > distributions) and I somewhat saw the development of this feature
> > > > across rpm, rpm-config-SUSE, and the implementation in openSUSE
> > > > Tumbleweed.
> > > Understood.  FWIW, I work closely with Martin L, Martin J, Jan and
> > > Richi @ SuSE.  Martin L and I in particular coordinate on mass build
> > > testing & related failure analysis and bugfixing.
> > >
> >
> > Martin Liška is the one I've primarily interfaced with throughout the
> > implementation.
> >
> > I don't know if you know about this, but there's a tracker bug for
> > LTO-related failures: https://bugzilla.opensuse.org/1133084
> I am aware of it and have referenced it several times in my own work.
>
> >
> > We should probably make sure this is cross-referenced as LTO is
> > implemented in Fedora.
> Sure.  That's easy enough to do.  Some of the information is dated, but
> there still useful nuggets in there.
>
> They punted lots of stuff though.  In particular they punted the
> configure problem and middle-end issued diagnostics, which was terribly
> unfortunate.
>
> >
> > > > However, the implementation of LTO in openSUSE caused major problems
> > > > for "weaker" architectures like ARM and RISC-V. In Fedora, ARM is
> > > > co-primary with the rest of the architectures (ARM is allowed to be
> > > > broken in openSUSE from time to time). The major problems we
> > > > encountered was increased miscompilation errors and timeouts due to
> > > > builds taking even longer with LTO straining ARM build environments.
> > > Yes.  The 32bit architectures in particular are expected to be slightly
> > > problematical due to the limited address space.  Even with Jan's work
> > > in this area, I expect things like firefox to simply be too big to
> > > compile/link using LTO on the 32bit platforms.
> > >
> > > When I discussed this with Martin L and one of the Ubuntu engineers
> > > (Matthias) back in Sept, the general plan we agreed on was to first get
> > > the Fedora test builds in reasonable shape on x86_64 that we could use
> > > as a baseline (and we're just about there).  Then do an i686 build for
> > > comparison purposes.
> > >
> > > For packages we find problematical on the 32bit platforms, we'll be
> > > able to trivially opt-out of LTO for that package on those 32bit
> > > platforms.  It's a one-liner in the .spec file.
> > >
> > >
> >
> > Are we going to use the same %_lto_cflags mechanism that was
> > implemented in openSUSE, or are we going to do something different?
> Ideally the same.  I don't own redhat-rpm-config, but certainly my
> preference is use the same mechanisms.
>
> >
> >
> > I'd like to see at *least* AArch64 spun to see how well this goes. I'm
> > reasonably confident that POWER8+ would be fine, since we don't have
> > ppc64be anymore (and I *know* that one was broken, since I reported it
> > years ago: https://bugzilla.redhat.com/1515934).
> Obviously aarch64 will be built and any issues resolved as is the case
> with other architectures.  We do this every spring cycle with the
> introduction of a major GCC release and we work closely with the GCC
> engineers at ARM and IBM along the way.
>
> Building 9000 packages 3X each (gcc-10+LTO, gcc-10, gcc-9 baseline)
> takes significant hardware.  If there's hardware I can use (and you
> should be thinking on the order of dozens of dedicated machines), then
> I'm happy to use them.  I mentioned ppc64le simply because I can get
> access to a goodly number of them.

Is there a reason you couldn't use aarch64 AWS instances?

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

Fedora-Rawhide-20191221.n.0 compose check report

2019-12-21 Thread Fedora compose checker 
No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 4/155 (x86_64), 1/2 (arm)

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

ID: 501082  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/501082
ID: 501097  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/501097
ID: 501137  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/501137
ID: 501145  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/501145
ID: 501215  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/501215

Soft failed openQA tests: 87/155 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20191218.n.0):

ID: 501197  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/501197

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

ID: 501063  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/501063
ID: 501064  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/501064
ID: 501068  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/501068
ID: 501069  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/501069
ID: 501070  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/501070
ID: 501071  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/501071
ID: 501072  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/501072
ID: 501073  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/501073
ID: 501074  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/501074
ID: 501076  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/501076
ID: 501077  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/501077
ID: 501088  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/501088
ID: 501093  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/501093
ID: 501096  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/501096
ID: 501102  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/501102
ID: 501103  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/501103
ID: 50  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/50
ID: 501116  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/501116
ID: 501129  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/501129
ID: 501134  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/501134
ID: 501139  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/501139
ID: 501140  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/501140
ID: 501141  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/501141
ID: 501142  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/501142
ID: 501143  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/501143
ID: 501146  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/501146
ID: 501147  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/501147
ID: 501148  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/501148
ID: 501149  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/501149
ID: 501150  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/501150
ID: 501152  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/501152
ID: 501153  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/501153
ID: 501154  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.

Re: fstrim and LUKS [Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default]

2019-12-21 Thread John M. Harris Jr 
On Saturday, December 21, 2019 1:59:03 AM MST Vitaly Zaitsev via devel wrote:
> On 20.12.2019 21:53, Chris Murphy wrote:
> 
> > If your LUKS drives are listed in fstab, they will have fstrim issued
> > and it will pass down to the physical drive.
> 
> 
> Only with enabled discard option in /etc/crypttab, because trimming of
> LUKS significantly decrease security level (everyone even without
> password/key knowledge can identify that drive contains LUKS filesystem
> and used disk space).

That's already a default in Fedora, as we've already made that trade-off. This 
is why I personally wouldn't use TRIM, but I can certainly see how it'd be 
useful to those who are actually looking for longevity (not performance, TRIM 
doesn't get you better performance) over security.

-- 
John M. Harris, Jr.
Splentity

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

Re: fstrim and LUKS [Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default]

2019-12-21 Thread Vitaly Zaitsev via devel 
On 20.12.2019 21:53, Chris Murphy wrote:
> If your LUKS drives are listed in fstab, they will have fstrim issued
> and it will pass down to the physical drive.

Only with enabled discard option in /etc/crypttab, because trimming of
LUKS significantly decrease security level (everyone even without
password/key knowledge can identify that drive contains LUKS filesystem
and used disk space).

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

Re: fstrim and LUKS [Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default]

2019-12-21 Thread Vitaly Zaitsev via devel 
On 20.12.2019 21:30, Jan Kratochvil wrote:
> This is AFAIK not enough for LUKS drives, will it be supported for LUKS?

If you want to enable TRIM for LUKS, you should add discard option to
/etc/crypttab file.

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