Re: Three steps we could take to make supply chain attacks a bit harder

[Artem S. Tashkinov via devel]

This approach

> let's delete autoconf-generated cruft from upstream projects and regenerate 
> it in %prep

To me sounds woefully inappropriate for the task at hand. You remove a single 
attack vector while completely overlooking that many of your maintainers don't 
have the qualifications to vet the included code even if it's autoconf-cruft 
free.

AFAIK, the bad code discovered in XZ was on its way to the GIT repo, could have 
been included in a slightly different way and if not for the wonderful 
discovery by the Microsoft software engineer of all people, we'd be dealing 
with a whole much more terrible outcome.

The source code must be vetted. In a perfect world, considering the entire 
source code is available, an API calls map for each release could be 
built/extracted, so that whenever a new version is published by the upstream, a 
new map for the new release could easily show at least all the new API calls 
that the project now uses to easily discover whether new features correspond to 
what the project maintainer published in their changelog. Probably another 
"anti-freedom" proposal.

And of course, would be great to employ all the methods of automated software 
verification, like static analysis, sandboxing, fuzzying, etc. I'm just 
dreaming.

Let's pretend this incident is entirely about autoconf stuff, and not about a 
software project being hijacked by hostile actors. And of course, you're 
absolutely sure this hasn't already happened in other widely used projects and 
will never happen again.

Again, sorry for intervening. I just freaked out when I realized my Linux box 
might have been compromised after almost believing in the persistent myth of 
"multiple eyes" (five?) scanning open source software for malware. It's not 
been the case, the entire proposal that we are discussing here is not talking 
about it either. I'm confused.

Regards,
Artem
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Artem S. Tashkinov via devel]

I'm not sure my proposal has been understood at all.

This website/authority is a sort of advisory board where each member's 
participation is 100% voluntary and distros are free to **ignore** it 
altogether.

What this website will contain is just a nice list of vetted open source 
packages, versions and their hashes, signed by at least two independent parties 
(people or orgs, doesn't matter), that's it. Who's going to populate this 
website, is up to people to decide.

> This is just fundamentally not how Free Software works.

Fundamentally I don't understand your comment at all. The proposal of mine is 
not there to limit anyone's freedom, it's to provide guarantees that certain 
packages have been vetted (checked and verified to be malware free), and you 
are safe to use it.

Actually it's a huge stinking problem for a **ton** of open source users who 
want to install certain packages that their distros don't have. It's especially 
relevant for Fedora given it's a basically a precursor of RedHat and it cannot 
contain a ton of packages related to software patents.

As a result of it, BTW, your users blindly trust RPMFusion. A seemingly 
absolutely shady website with no official ties to RedHat, which guarantees 
neither that the packages it builds are malware free, nor that there are any 
actual people responsible for them. If there are RPMFusion maintainers here, 
I'm not here to insult you, I'm just relaying the status quo. RPMFusion does 
not look legit. I stopped using it over a decade ago because I simply cannot 
understand why I should trust it. If RedHat denies anything patent related, 
there's zero legal obligations for RedHat if someone starts spreading malware 
via it. That sucks.

Back to the topic.

Then you have to painstakingly scour the web for distros already using this 
package and check whether their have the same version with a hash. Then you 
download the package and verify the hash and pray to God the distro has at 
least given a cursory look to this package, so it's actually safe to install.

I guess I'm not coming from @fedora.org or @redhat.com, so my proposal is 
"anti-freedom".

Sorry for wasting your time. You have not even provided the very basic 
counter-arguments why my proposal makes no sense.

RedHat absolutely can start this initiative. You have all the means and 
resources, and I'm not talking about something super complex or expensive. For 
all I know, it could be the most basic website running on top of SQLite which 
costing the company $50 a month to run.

And of course, without this website, distros will continue to valiantly include 
upstream packages and get royally screwed and screw their poor users because a 
ton of your maintainers have neither the time/resources, nor qualifications to 
check whether the code you happily push to users is malware free.

I guess we'll have to have a few more accidents like this before someone will 
come up with a similar solution only not coming from me personally, because I'm 
a no one and just rending the air.

Sorry for intervening,
Artem
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Artem S. Tashkinov via devel]

Hi,

It was sheer luck that the exploit was discovered and major distros haven't yet 
included it in their stable releases. It's quite possible and plausible it 
could have reached RHEL, Debian, Ubuntu, SLES and other distros and it's almost 
reached Fedora 40.

I don't know how to talk to RedHat/IBM/FSF/Ubuntu and all the big players 
behind Open Source/Linux but I want to raise a very important issue.

There's near zero accountability for the tens of thousands of packages included 
in Linux distros, often by maintainers who have no resources, qualifications or 
even know any programming languages to spot the "bad" code and raise an alarm. 
Upstream packages are pushed into Linux distros without considerationand that's 
it.

That's all completely unacceptable on multiple levels. Security is a joke as a 
result of this considering the infamous "Jia Tan" who was almost the sole 
maintainer of XZ for over two years.

I propose this issue to be tackled in a centralized way by the collaboration of 
major distros.

There must be a website or a central authority which includes known to be 
good/safe/verified/vetted open source packages along with e.g. 
SHA256/384/512/whatever hashes of the source tarballs. In addition, the source 
tarballs (not their compressed versions because people may use different 
compressors and compression settings) and their hashes must be digitally signed 
or have the appropriate PGP signatures from the trusted parties.

Some parties must be assigned trust to be able to push new packages to this 
repository. Each push must be verified by at least two independent parties, 
let's say RedHat and Ubuntu or Ubuntu and Arch, it doesn't matter. The 
representatives of these parties must be people whose whereabouts are known to 
confirm who they physically are. No nicknames allowed.

This website must also have/allow a revocation mechanism for situations like 
this.

Now Fedora/Arch/Debian/Ubuntu/whatever distros can build packages knowing they 
are safe to use.

If that's the wrong place to come up with this proposal, please forward it to 
the people who are responsible for making such decisions. I'm not willing to 
dig through the dirt to understand how the Fedora project works, who is 
responsible for what, and what are the appropriate communication channels. If 
you care, you'll simply forward my message. Thanks a lot.

Best regards,
Artem
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F36 to F37

[Stuart S]

I've just tried this for Fed 35 >> Fed 37

Got the following errors

 Problem: conflicting requests
  - nothing provides module(platform:f35) needed by module 
php:remi-7.4:20230104141955:.x86_64
Error: 
 Problem 1: package php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64 requires 
php(api) = 20190902-64, but none of the providers can be installed
  - package php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64 requires 
php(zend-abi) = 20190902-64, but none of the providers can be installed
  - php-common-7.4.33-2.fc35.remi.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package 
php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64
 Problem 2: package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 requires 
libQt5Core.so.5(Qt_5.15.2_PRIVATE_API)(64bit), but none of the providers can be 
installed
  - package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 requires qt5-qtbase(x86-64) = 
5.15.2, but none of the providers can be installed
  - qt5-qtbase-5.15.2-31.fc35.x86_64 does not belong to a distupgrade repository
  - problem with installed package qt5-qtenginio-1:1.6.2-36.fc35.x86_64
(try to add '--skip-broken' to skip uninstallable packages)


I know this is not a help page but can someone point me in right direction as I 
can't find it...

Cheers
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libharu soname bump in rawhide [part II]

[Dmitrij S. Kryzhevich]

hpdf.h includes hpdf_version.h frpm 2.4.3 which is ready for rawhide.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libharu soname bump in rawhide [part II]

[Dmitrij S. Kryzhevich]

If you need help with updating please note me.

--
Dmitrij S. Kryzhevich
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

libharu soname bump in rawhide [part II]

[Dmitrij S. Kryzhevich]

libharu is going to be updated with soname bump in the near future. This is a 
second attempt [1].
There is an ABI change AND API change: HPDF_Page_SetDash() and 
HPDF_Page_Create3DAnnot().

Syntax change.
1. HPDF_Page_Create3DAnnot()
was: HPDF_Page page, HPDF_Rect rect, HPDF_U3D u3d
new: HPDF_Page page, HPDF_Rect rect, HPDF_BOOL tb, HPDF_BOOL np, HPDF_U3D u3d, 
HPDF_Image ap
where:
tb - enable visibility of ToolBar
np - enable visibility of Navigation Panel
ap - not described, referenced to pointer where 'appearance' should be 
stored, but could be NULL so internal 'HPDF_Dict stream' will be used instead.

2. HPDF_Page_SetDash()
was: HPDF_Page page, const HPDF_UINT16 *dash_ptn, HPDF_UINT num_param, 
HPDF_UINT phase
new: HPDF_Page page, const   HPDF_REAL *dash_ptn, HPDF_UINT num_param, 
HPDF_REAL phase
so it's 'dash_ptn' and 'phase'
gcc will throw error with signed-unsigned convertion if not fixed. Error could 
be disabled with corresponding flag (but obviously should not).

Also hpdf.h does not include hpdf_version.h now. There is an issue opened in 
libharu apstream [2] which may be resolved.

Affected packages:
vtk
saga
mathgl
EMBOSS
plplot
perl-PDF-Haru
blender

Looks like blender and EMBOSS does not use those API and could be just rebuilt. 
Others rely on it.

I haven't permissions of proven packager so can't rebuild them (except mathgl 
where I'm comaintainer).

--
Dmitrij S. Kryzhevich

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZV4NIK4TRWYM666B46YHQ2HAMJ6RDS27/
[2] https://github.com/libharu/libharu/issues/246
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libharu soname bump for rawhide

[Dmitrij S. Kryzhevich]

Oh. Found error in my repoquery. Thank you.

On Wed, 5 Oct 2022 22:11:31 +0900
Mamoru TASAKA  wrote:

> Dmitrij S. Kryzhevich wrote on 2022/10/05 18:02:
> > I understand the necessity of time to react, may be should handle it in a 
> > more proper way.
> > I was triggered by maintainer of only dependent package (directly 
> > dependent) so I strongly believe it's OK in this case.
> 
> Seems not actually:
> 
> dnf repoquery --repo=koji-38  --qf '%{sourcerpm}' --whatrequires 
> "libhpdf.so.2.3*" | cat -n
>   1   EMBOSS-6.6.0-22.fc38.src.rpm
>   2   blender-3.3.0-4.fc38.src.rpm
>   3   mathgl-2.4.4-18.fc38.src.rpm
>   4   perl-PDF-Haru-1.00-38.fc37.src.rpm
>   5   plplot-5.15.0-45.fc38.src.rpm
>   6   saga-7.6.1-16.fc38.src.rpm
>   7   vtk-9.1.0-17.fc37.src.rpm
> 
> Perhaps I am going to request untag for libharu-2.4.2-1.fc38.
> 
> Regards,
> Mamoru
> 
> 
> > 
> > On Wed, 5 Oct 2022 10:51:20 +0200
> > Fabio Valentini  wrote:
> > 
> >> On Wed, Oct 5, 2022 at 9:24 AM Dmitrij S. Kryzhevich  
> >> wrote:
> >>>
> >>> New version of libharu is building for rawhide with coresponding soname 
> >>> bump.
> >>> Only vtk should be affected right now.
> >>
> >> I see that you have already built libharu-2.4.2-1.fc38.
> >>
> >> Did you also handle rebuilding dependent packages, or should their
> >> maintainers handle that themselves?
> >> Usually there should be one week between such heads-up emails and
> >> pushing the actual build, especially when you don't rebuild dependent
> >> packages.
> >>
> >> Fabio
> >> ___
> >> 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, report it: 
> >> https://pagure.io/fedora-infrastructure/new_issue
> > ___
> > 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, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> ___
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libharu soname bump for rawhide

[Dmitrij S. Kryzhevich]

I understand the necessity of time to react, may be should handle it in a more 
proper way.
I was triggered by maintainer of only dependent package (directly dependent) so 
I strongly believe it's OK in this case.

On Wed, 5 Oct 2022 10:51:20 +0200
Fabio Valentini  wrote:

> On Wed, Oct 5, 2022 at 9:24 AM Dmitrij S. Kryzhevich  wrote:
> >
> > New version of libharu is building for rawhide with coresponding soname 
> > bump.
> > Only vtk should be affected right now.
> 
> I see that you have already built libharu-2.4.2-1.fc38.
> 
> Did you also handle rebuilding dependent packages, or should their
> maintainers handle that themselves?
> Usually there should be one week between such heads-up emails and
> pushing the actual build, especially when you don't rebuild dependent
> packages.
> 
> Fabio
> ___
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

libharu soname bump for rawhide

[Dmitrij S. Kryzhevich]

New version of libharu is building for rawhide with coresponding soname bump. 
Only vtk should be affected right now.

--
Dmitrij S. Kryzhevich
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F36 to F37

[Timo S via devel]

$ sudo dnf --releasever=37 --setopt=module_platform_id=platform:f37 
--enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) --assumeno distro-sync
Last metadata expiration check: 0:08:47 ago on Tue 13 Sep 2022 19:34:54.
Error: 
 Problem 1: problem with installed package nodejs-electron-19.0.16-1.3.x86_64
  - package nodejs-electron-19.0.16-1.4.x86_64 requires libavif.so.13()(64bit), 
but none of the providers can be installed
  - nodejs-electron-19.0.16-1.3.x86_64 does not belong to a distupgrade 
repository
  - libavif-0.9.3-3.fc36.x86_64 does not belong to a distupgrade repository
 Problem 2: problem with installed package 0ad-0.0.25b-2.fc36.x86_64
  - package 0ad-0.0.25b-2.fc36.x86_64 requires 
libboost_filesystem.so.1.76.0()(64bit), but none of the providers can be 
installed
  - boost-filesystem-1.76.0-12.fc36.x86_64 does not belong to a distupgrade 
repository
 Problem 3: problem with installed package signal-desktop-5.58.0-1.7.x86_64
  - package signal-desktop-5.58.0-1.7.x86_64 requires (nodejs-electron(x86-64) 
>= 19 with nodejs-electron(x86-64) < 20), but none of the providers can be 
installed
  - package nodejs-electron-19.0.16-1.3.x86_64 requires libjxl.so.0.6()(64bit), 
but none of the providers can be installed
  - package nodejs-electron-19.0.16-1.3.x86_64 requires 
libjxl.so.0.6(JXL_0)(64bit), but none of the providers can be installed
  - package nodejs-electron-19.0.16-1.4.x86_64 requires libjxl.so.0.6()(64bit), 
but none of the providers can be installed
  - package nodejs-electron-19.0.16-1.4.x86_64 requires 
libjxl.so.0.6(JXL_0)(64bit), but none of the providers can be installed
  - libjxl-0.6.1-9.fc36.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Request for testing: Fedora 37 pre-Beta validation tests

[Leslie S Satenstein via devel]

Hi Adam
Always on a long weekend. I have an issue with the installation of the 
workspace 37beta.  
BTW, rawhide is OK for installation (clear images), ditto for reinstallation of 
F36live.

Am I the only one getting screen corruption with anaconda and with some parts 
of Workspace 37.  
I am getting active snow flakes in the frames of pages, and within the 
contents, both for anaconda and the live workspace installationI am still able 
to click on the options, but feel that someone should verify that I am not 
alone with this issue.I used the version in the web page  -dated 0831.

I am retesting with the 0901 version and will get back to you.

Regards 
 Leslie
 Leslie Satenstein
Montréal Québec, Canada

 

On Monday, August 29, 2022 at 08:22:54 p.m. EDT, Adam Williamson 
 wrote:  
 
 Hey folks!

So we're in freeze for Fedora 37 Beta now, and the first go/no-go
meeting should be on September 8.

It would be really great if we can get the validation tests run now so
we can find any remaining blocker bugs in good time to get them fixed.
Right now the blocker list looks short, but there are definitely some
tests that have not been run.

You can use the testcase_stats view to find tests that need running:

https://openqa.fedoraproject.org/testcase_stats/37/

For each validation test set (Base, Desktop etc.) it shows when each
test was last performed. So you can easily look for Basic and Beta
tests that have not yet been run. We need to run all of these.

You can enter results using `relval report-results`, or edit the
summary results page at
https://fedoraproject.org/wiki/Test_Results:Current_Summary . That's a
redirect link which will always point to the validation results page
for the currently-nominated compose, which right now is 20220826.n.0.

Sumantro will be running a validation 'test week' starting on
Wednesday, so you can drop by the Fedora Test Day room on
chat.fedoraproject.org to hang out with other testers and get any help
you need in testing. See
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org/message/KVVU6JVOKF4WI4ZS6AFLB7IVBCCNKFCX/
for that announcement.

Thanks folks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
kde mailing list -- k...@lists.fedoraproject.org
To unsubscribe send an email to kde-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/k...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
  ___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads-up / for discussion: dnf not working with 1G of RAM or less

[Leslie S Satenstein via devel]

What is the contents of /etc/dnf/dnf.conf
It might help to see if there is a setting therein that is causing the 
mentioned issue.

Regards 
 Leslie
 Leslie Satenstein
Montréal Québec, Canada

 

On Sunday, August 28, 2022 at 11:24:30 p.m. EDT, Adam Williamson 
 wrote:  
 
 Hey folks! I apologize for the wide distribution, but this seemed like
a bug it'd be appropriate to get a wide range of input on.

There's a bug that was proposed as an F37 Beta blocker:
https://bugzilla.redhat.com/show_bug.cgi?id=1907030

it's quite an old bug, but up until recently, the summary was
apparently accurate - dnf would run out of memory with 512M of RAM, but
was OK with 1G. However, as of quite recently, on F36 at least (not
sure if anyone's explicitly tested F37), dnf operations are commonly
failing on VMs/containers with 1G of RAM due to running out of RAM and
getting OOM-killed.

There's some discussion in the bug about what might be causing this and
potential ways to resolve it, and please do dig into/contribute to that
if you can, but the other question here I guess is: how much do we care
about this? How bad is it that you can't reliably run dnf operations on
top of a minimal Fedora environment with 1G of RAM?

This obviously has some overlap with our stated hardware requirements,
so here they are for the record:

https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/

that specifies 2GB as the minimum memory for "the default
installation", by which I think it's referring to a default Workstation
install, though this should be clarified. But then there's a "Low
memory installations" boxout, which suggests that "users with less than
768MB of system memory may have better results performing a minimal
install and adding to it afterward", which kinda is recommending that
people do exactly the thing that doesn't work (do a minimal install
then use dnf on it), and implying it'll work.

After some consideration I don't think it makes sense to take this bug
as an F37 blocker, since it already affects F36, and that's what I'll
be suggesting at the next blocker review meeting. However, it does seem
a perfect candidate for prioritized bug status, and I've nominated it
for that.

I guess if folks can chime in with thoughts here and/or in the bug
report, maybe a consensus will emerge on just how big of an issue this
is (and how likely it is to get fixed). There will presumably be a
FESCo ticket related to prioritized bug status too.

Thanks folks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
kde mailing list -- k...@lists.fedoraproject.org
To unsubscribe send an email to kde-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/k...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
  ___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: proposal idea: EOL notifications

[Artém S . Tashkinóv]

> I am not excited, because I feel it doesn't add any value to Fedora.

It's not about adding "value", it's about making sure that people
realize that they are running unsupported software which no longer
receives updates and might have vulnerabilities, including remote.
Actually, any now unsupported Fedora release has a ton of them. Maybe
that's totally OK for, that's totally not OK for me.

When a person installs a new shiny distro they are not obliged to
subscribe to distro news or mailing lists and that's exactly what most
people do.

Many run their Linux distro headless, so whatever Gnome guys may come up
with will not work for people who only use console/remote SSH shell.

Best regards,
Artem
___
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: Non-responsive maintainer check: fabiand - Fabian Deutsch

[Dmitrij S. Kryzhevich]

I suppose we can try this address as well: fdeut...@redhat.com
(I hope it's correct)

Dmitrij Kryzhevich

On Sun, 13 Feb 2022 20:22:46 -0500
Noah Palmer  wrote:

> Hello,
> I am starting the non-responsive maintainer process for fabiand. He is the
> listed maintainer for 20 packages and as far as I can tell has been
> unresponsive for a long time
> fedora-active-user lists the last email on a mailing list in 2013 and I
> can't find any actively within the past few years. python-uinput has been
> broken since at least 2017 to it not being updated.
> This bug recommended starting the non-responsive maintainer check:
> https://bugzilla.redhat.com/show_bug.cgi?id=1356751
> 
> non-responsive maintainer check:
> https://bugzilla.redhat.com/show_bug.cgi?id=2054018
> 
> Does anyone know him, or if he is still active? If not I would like to see
> if I can adopt python-uinput. I've always wanted to get involved with
> fedora and this seems like a great opportunity.
> -- 
> Noah Palmer
___
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: Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

[Anoop C S via devel]

On Fri, 2022-01-21 at 15:41 +0530, Anoop C S via devel wrote:
> On Fri, 2022-01-21 at 10:32 +0100, Pierre-Yves Chibon wrote:
> > On Fri, Jan 21, 2022 at 02:31:57PM +0530, Anoop C S wrote:
> > > On Thu, 2022-01-20 at 09:57 +0100, Pierre-Yves Chibon wrote:
> > > > Good Morning Everyone,
> > > > 
> > > > The packagers listed here have been receiving a daily email
> > > > asking
> > > > them to
> > > > either adjust their bugzilla or their FAS account so the email
> > > > address in FAS
> > > > matches an existing bugzilla account.
> > > > 
> > > > Having a bugzilla account is mandatory per:
> > > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> > > > 
> > > > - anoopcs contacted since November 27th
> > > > 
> > > > anoopcs is maintainer of rpms/glusterfs
> > > > anoopcs is main admin of rpms/glusterfs-coreutils
> > > > anoopcs has a bugzilla override on rpms/glusterfs-coreutils
> > > > anoopcs is maintainer of rpms/richacl
> > > > anoopcs is maintainer of rpms/samba
> > > > anoopcs is watching rpms/socket_wrapper
> > > 
> > > I am aware and was ignoring it based on the reply I got for the
> > > ticket
> > > raised[1] on the exact same issue. I also wanted to know where
> > > the
> > > ongoing work for making use of bugzilla field in FAS(I made
> > > another
> > > comment after ticket got closed) is being tracked. May be issue
> > > #9863[2]?
> > 
> > That's a question I do not have the answer to.
> > 
> 
> Fine. I'll keep an eye on #9863 for now.
> 
> > > Very recent request(via email) for bugzilla email validation gave
> > > me an
> > > impression that its finally gonna happen.
> > 
> > It is being worked on but it is not ready yet (I expect that it
> > will
> > be
> > announced once it is).
> > 
> > > If not, how important it is to match both(FAS and bugzilla) email
> > > addresses at this point? Or is it a requirement now to have same
> > > email
> > > address to get the work completed? Sorry, I am little confused.
> > 
> > It is important as it breaks the sync from dist-git to bugzilla and
> > for the
> > entire component (package), so it impacts you as well as
> > potentially
> > any other
> > co-maintainers or watchers of the packages you are linked to.
> > 
> > Currently there are two ways to get this sync working:
> > - either have a valid bugzilla account corresponding to your main
> > FAS
> > email
> 
> May be not.
> 
> > - add an override to manually map your main FAS email to your
> > bugzilla account
> >   in:
> >  
> > https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/toddlers/templates/email_overrides.toml
> 
> Ahaa..for the time being, I'll go for an email override. In that case
> I hope a ticket is expected?

PR #934[1] is up for review. Let me know if something else is required.

[1] https://pagure.io/fedora-infra/ansible/pull-request/934


Thanks,
Anoop C S.
___
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: Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

[Anoop C S via devel]

On Fri, 2022-01-21 at 10:32 +0100, Pierre-Yves Chibon wrote:
> On Fri, Jan 21, 2022 at 02:31:57PM +0530, Anoop C S wrote:
> > On Thu, 2022-01-20 at 09:57 +0100, Pierre-Yves Chibon wrote:
> > > Good Morning Everyone,
> > > 
> > > The packagers listed here have been receiving a daily email
> > > asking
> > > them to
> > > either adjust their bugzilla or their FAS account so the email
> > > address in FAS
> > > matches an existing bugzilla account.
> > > 
> > > Having a bugzilla account is mandatory per:
> > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> > > 
> > > - anoopcs contacted since November 27th
> > > 
> > > anoopcs is maintainer of rpms/glusterfs
> > > anoopcs is main admin of rpms/glusterfs-coreutils
> > > anoopcs has a bugzilla override on rpms/glusterfs-coreutils
> > > anoopcs is maintainer of rpms/richacl
> > > anoopcs is maintainer of rpms/samba
> > > anoopcs is watching rpms/socket_wrapper
> > 
> > I am aware and was ignoring it based on the reply I got for the
> > ticket
> > raised[1] on the exact same issue. I also wanted to know where the
> > ongoing work for making use of bugzilla field in FAS(I made another
> > comment after ticket got closed) is being tracked. May be issue
> > #9863[2]?
> 
> That's a question I do not have the answer to.
> 

Fine. I'll keep an eye on #9863 for now.

> > Very recent request(via email) for bugzilla email validation gave
> > me an
> > impression that its finally gonna happen.
> 
> It is being worked on but it is not ready yet (I expect that it will
> be
> announced once it is).
> 
> > If not, how important it is to match both(FAS and bugzilla) email
> > addresses at this point? Or is it a requirement now to have same
> > email
> > address to get the work completed? Sorry, I am little confused.
> 
> It is important as it breaks the sync from dist-git to bugzilla and
> for the
> entire component (package), so it impacts you as well as potentially
> any other
> co-maintainers or watchers of the packages you are linked to.
> 
> Currently there are two ways to get this sync working:
> - either have a valid bugzilla account corresponding to your main FAS
> email

May be not.

> - add an override to manually map your main FAS email to your
> bugzilla account
>   in:
>  
> https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/toddlers/templates/email_overrides.toml

Ahaa..for the time being, I'll go for an email override. In that case I
hope a ticket is expected?

Thanks for the pointers.

-Anoop C S.
___
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: Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

[Anoop C S via devel]

On Thu, 2022-01-20 at 09:57 +0100, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> The packagers listed here have been receiving a daily email asking
> them to
> either adjust their bugzilla or their FAS account so the email
> address in FAS
> matches an existing bugzilla account.
> 
> Having a bugzilla account is mandatory per:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> 
> - anoopcs contacted since November 27th
> 
> anoopcs is maintainer of rpms/glusterfs
> anoopcs is main admin of rpms/glusterfs-coreutils
> anoopcs has a bugzilla override on rpms/glusterfs-coreutils
> anoopcs is maintainer of rpms/richacl
> anoopcs is maintainer of rpms/samba
> anoopcs is watching rpms/socket_wrapper

I am aware and was ignoring it based on the reply I got for the ticket
raised[1] on the exact same issue. I also wanted to know where the
ongoing work for making use of bugzilla field in FAS(I made another
comment after ticket got closed) is being tracked. May be issue
#9863[2]?

Very recent request(via email) for bugzilla email validation gave me an
impression that its finally gonna happen.

If not, how important it is to match both(FAS and bugzilla) email
addresses at this point? Or is it a requirement now to have same email
address to get the work completed? Sorry, I am little confused.

Regards,
Anoop C S.

[1] https://pagure.io/fedora-infrastructure/issue/10404
[2] https://pagure.io/fedora-infrastructure/issue/9863
___
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: Btrfs question for Fedora 33 beta. How can I add nocow to /var

[Leslie S Satenstein via devel]

Fedora Everything Presentation from youtube. 
https://www.youtube.com/watch?v=qOv-EFdVoss

Regards 
 Leslie
 Leslie Satenstein
Montréal Québec, Canada

 

On Sunday, October 25, 2020, 10:38:33 p.m. EDT, Chris Murphy 
 wrote:  
 
 On Sun, Oct 25, 2020 at 6:56 PM Leslie Satenstein via devel
 wrote:
>
> Hi  Chris,
>
> This weekend past, I did create /opt and /var as subvolumes.  For the empty 
> /opt, it was easy. For /var, it took the live ISO to help with moving 
> directory /var to subvolume /var.

Recommended reading.
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout

The "flat" method for /var means it actually gets swapped from the
'old dir var' to 'new subvolume var' at reboot time via the fstab
entry resulting in it being mounted on /var. You can mount the Btrfs
file system again at /mnt and clean out the root/var directory. There
is a sort of "through the looking glass" experience with "flat"
layout. I often regret not giving subvolumes names different from
their mount point if I use this layout style. So instead of a "var"
subvolume mounted at /var, I'll name it var33 (i.e. var for Fedora
33). Maybe we'll end up using native system mount units for these
kinds of things so that fstab isn't overly complicated.

The "nested" layout just substitutes in-place, no need for fstab
entry. Way simpler. Except if you ever have to do a rollback, and then
you have to move it into the new location before the rollback. That
isn't always possible or maybe you wouldn't have to rollback in the
first place.

> I also intend to do the same with /sys on this, my beta system,

I'm not sure about this. /sys is a pseudo-filesystem, the contents
aren't really on the root file system.


> The rational for my doing the subvolume exercise is the following:
> 1) Under default installation, each snapfile of root has a copy of  all 
> subdirectories including active /var, and /sys. I noted that /var/log and 
> /var/cache is rather volatile. My SSD size is 120gigs
> 2) By isolating /var, /opt and /sys  the root snapshot becomes less bloated.

/var contains the rpm database, which means at least /var/lib/rpm is
tied to /usr and to some degree /boot.  That means any need to
rollback one requires rolling back all in conjunction. And yet
/var/log is one thing we probably do not want to rollback, and
possibly the same for /var/cache in its entirety. But...
work-in-progress.

> 4) But /var/log is quite active, as is /var/cache.  I will be using btrfs 
> defragment on /var.

If it's a (spinning) HDD it might be suited for the autodefrag mount
option so long as the workload isn't heavy database use. Autodefrag is
intended for light database use like web browsers, and spinning
drives. There's a proposal upstream to make it a settable property so
it can be enabled selectively, rather than as a mount option. I don't
ever defragment SSD/NVMe.

I think you're better off using bcc-tools' fileslower to evaluate if
there are unexpected latencies happening. And quantifying how much
defragmenting solves the problem. You can further narrow these down
the source of latency with btrfsdist, btrfsslower and biolatency.
(There are ext4 and xfs equivalents.)

> 5) Having /var as nodatacow puts /var to the same risk level as when /var was 
> on the ext4 system.

If you're wanting to save space, you may want to experiment with
compression. And nodatacow means no compression. I think you want to
be more selective with nodatacow for very specific reasons and already
the top candidate for that already get's nodatacow set automatically
by libvirt when a storage pool is created.

>
> I will be using fstrim -a (to do SSD trims) and I want to user snapper, to 
> manage the subvolume snapshots. The generations of snapshots for /var and / 
> will be my objective.
> I will be using crontab and a script to take snapshots just before  the 
> script launches  "sudo dnf update -y".

OK you might want to look at the dnf snapper plugin for this.

> This switch to btrfs  is a learning experience for me.  Fedora is my passion, 
> From my studies, I may discover that you are absolutely right to state that I 
> do not need to make the extra subvolumes.
> The advantage I have over you is my career. It is called "retirement"­. 
> Retirement comes with spare time to study, to learn, to write code, to 
> explore, experiment and to share experiences.

Cool! Have fun!

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

Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var

[Leslie S Satenstein via devel]

Thank you all.
Is it worthwhile putting compress=lzo  for root. Without concern, I have done 
it for /home.

Regards 
 Leslie
 Leslie Satenstein
Montréal Québec, Canada

 

On Monday, October 26, 2020, 2:17:40 a.m. EDT, Ian Kent  
wrote:  
 
 On Sun, 2020-10-25 at 20:38 -0600, Chris Murphy wrote:
> On Sun, Oct 25, 2020 at 6:56 PM Leslie Satenstein via devel
> 
> > I also intend to do the same with /sys on this, my beta system,
> 
> I'm not sure about this. /sys is a pseudo-filesystem, the contents
> aren't really on the root file system.

That's right, like /proc is a proc file system, /sys is a sysfs file
system (similar to other pseudo file systems). They are memory based
and files are generated on access, proc files mostly directly from
kernel data structures, and sysfs mostly from an rb-tree data structure
within the sysfs file system populated at boot.

You must mount /sys as a sysfs file system in order for the rb-tree
to be populated, you can't make it a btrfs file system (or any other
file system for that matter).

Ian

  ___
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: Btrfs question for Fedora 33 beta. How can I add nocow to /var

[Leslie S Satenstein via devel]

Hi Chris
I am again attaching a program  for you to try.I AM THE AUTHOR.  Extended to 
manage btrfs entries.

fstabxref -o /tmp/fstab
It reads the /dev/disk/by-xxx  contents,/etc/mtab and   
/etc/fstab
It validates each fstab entry  as it builds the output. 
Errors are pointed out.
In the process of coding it, if you have "btrfs sub create var"  at the 5 
levelmtab will show it as /var, 
ditto for the other subvols.
And changing the /etc/fstab to include the / before the var in the fstab as 
subvol=var appears to make no difference if it is 
subvol=var or subvol=/var
Things I discover.   If you look at other distros based on btrfs, the root00 is 
replaced by @so @home, ­@var etc are used.  For a while that @ thing stumped 
me. 
But then, I persisted.   

I am going to study your link's contents. 
My code is opensource and actually I find it very useful.  Use labels, UUIDs, 
PARTUUIDS, PARTLABELS, /dev/, 
my code handles it.  

If you find it useful and want the source git repro, just ask.

Regards 
 Leslie
 Leslie Satenstein
Montréal Québec, Canada

 

On Sunday, October 25, 2020, 10:38:33 p.m. EDT, Chris Murphy 
 wrote:  
 
 On Sun, Oct 25, 2020 at 6:56 PM Leslie Satenstein via devel
 wrote:
>
> Hi  Chris,
>
> This weekend past, I did create /opt and /var as subvolumes.  For the empty 
> /opt, it was easy. For /var, it took the live ISO to help with moving 
> directory /var to subvolume /var.

Recommended reading.
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout

The "flat" method for /var means it actually gets swapped from the
'old dir var' to 'new subvolume var' at reboot time via the fstab
entry resulting in it being mounted on /var. You can mount the Btrfs
file system again at /mnt and clean out the root/var directory. There
is a sort of "through the looking glass" experience with "flat"
layout. I often regret not giving subvolumes names different from
their mount point if I use this layout style. So instead of a "var"
subvolume mounted at /var, I'll name it var33 (i.e. var for Fedora
33). Maybe we'll end up using native system mount units for these
kinds of things so that fstab isn't overly complicated.

The "nested" layout just substitutes in-place, no need for fstab
entry. Way simpler. Except if you ever have to do a rollback, and then
you have to move it into the new location before the rollback. That
isn't always possible or maybe you wouldn't have to rollback in the
first place.

> I also intend to do the same with /sys on this, my beta system,

I'm not sure about this. /sys is a pseudo-filesystem, the contents
aren't really on the root file system.


> The rational for my doing the subvolume exercise is the following:
> 1) Under default installation, each snapfile of root has a copy of  all 
> subdirectories including active /var, and /sys. I noted that /var/log and 
> /var/cache is rather volatile. My SSD size is 120gigs
> 2) By isolating /var, /opt and /sys  the root snapshot becomes less bloated.

/var contains the rpm database, which means at least /var/lib/rpm is
tied to /usr and to some degree /boot.  That means any need to
rollback one requires rolling back all in conjunction. And yet
/var/log is one thing we probably do not want to rollback, and
possibly the same for /var/cache in its entirety. But...
work-in-progress.

> 4) But /var/log is quite active, as is /var/cache.  I will be using btrfs 
> defragment on /var.

If it's a (spinning) HDD it might be suited for the autodefrag mount
option so long as the workload isn't heavy database use. Autodefrag is
intended for light database use like web browsers, and spinning
drives. There's a proposal upstream to make it a settable property so
it can be enabled selectively, rather than as a mount option. I don't
ever defragment SSD/NVMe.

I think you're better off using bcc-tools' fileslower to evaluate if
there are unexpected latencies happening. And quantifying how much
defragmenting solves the problem. You can further narrow these down
the source of latency with btrfsdist, btrfsslower and biolatency.
(There are ext4 and xfs equivalents.)

> 5) Having /var as nodatacow puts /var to the same risk level as when /var was 
> on the ext4 system.

If you're wanting to save space, you may want to experiment with
compression. And nodatacow means no compression. I think you want to
be more selective with nodatacow for very specific reasons and already
the top candidate for that already get's nodatacow set automatically
by libvirt when a storage pool is created.

>
> I will be using fstrim -a (to do SSD trims) and I want to user snapper, to 
> manage the subvolume snapshots. The generations of snapshots for /var and / 
> will be my objective.
> I will be using crontab and a script to take snapshots just before  the 
> script launches  "sudo dnf update -y".

OK you might want to look at the dnf snapper plugin for this.

> This switch to btrfs  is a learning experience for me.  Fedora is my passion, 
> From my studie

Re: Kernel - default log levels

[David S.]

On 16/10/2020 18:57, Sven Kieske wrote:
> On Fr, 2020-10-16 at 15:27 +0200, David S. wrote:
>> My testing is currently on a standard Fedora 32 x86_64 running in
>> Digital Ocean (from their Fedora image pool).  It should be fairly
>> up-to-date (I see now there is a 5.8.15-201 kernel available).
>>
>> [root@davids-devtest-f32 ~]# uptime
>>  13:16:19 up 1 min,  1 user,  load average: 0.14, 0.04, 0.01
>> [root@davids-devtest-f32 ~]# uname -r
>> 5.8.14-200.fc32.x86_64
>> [root@davids-devtest-f32 ~]# cat /proc/sys/kernel/printk
>> 74   1   7
>> [root@davids-devtest-f32 ~]# grep LOGLEVEL_DEFAULT 
>> /boot/config-5.8.14-200.fc32.x86_64
>> CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
>> CONFIG_CONSOLE_LOGLEVEL_QUIET=3
>> CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
>>
>> I see the same printk values and config settings in the 5.8.15-201.
>>
>> I also don't see any tweaks to the kernel cmdline, so I'm also wondering what
>> else can be setting these values.
> 
> For what it's worth, here is the output from my unaltered F32 installation
> as an additional data point (the kernel is slighty older):
> 
> uname -r
> 
> 5.8.13-200.fc32.x86_64
> 
> cat /proc/sys/kernel/printk
> 
> 3   4   1   7
> 
> 
> grep LOGLEVEL_DEFAULT /boot/config-$(uname -r)
> 
> CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
> 
> CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4


Thanks for the input!  This is valuable.  I begin to wonder if Digital
Ocean has applied additional config tweaks now.  And I was a bit unclear
with "standard Fedora 32", as it is the Cloud edition.

But would be helpful to get some input on how these values can be
configured outside of the kernel config and kernel command line - if
alternative approaches exists.


-- 
kind regards,

David Sommerseth
OpenVPN Inc
___
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: Kernel - default log levels

[David S.]

On 16/10/2020 01:09, Justin Forbes wrote:
> On Tue, Oct 13, 2020 at 4:24 PM David S.  wrote:
>>
>>
>> Hi,
>>
>> I just spotted that there is a difference in the default log levels on
>> Fedora and RHEL-8 vs RHEL-7.
>>
>> Fedora/RHEL-8 uses:
>>
>># cat /proc/sys/kernel/printk
>>7   4   1   7
>>
>> while RHEL-7 uses:
>>
>># cat /proc/sys/kernel/printk
>>2   4   1   7
>>
>> I also see that this seems to have been changed in the the packaging
>>
> 
> Which kernel are you working with?  Rawhide kernels by default are
> typically debug kernels and will behave much differently in this
> regard.  Stable kernel releases are defaulting to 3 4 1 7
> 

My testing is currently on a standard Fedora 32 x86_64 running in
Digital Ocean (from their Fedora image pool).  It should be fairly
up-to-date (I see now there is a 5.8.15-201 kernel available).

[root@davids-devtest-f32 ~]# uptime
 13:16:19 up 1 min,  1 user,  load average: 0.14, 0.04, 0.01
[root@davids-devtest-f32 ~]# uname -r
5.8.14-200.fc32.x86_64
[root@davids-devtest-f32 ~]# cat /proc/sys/kernel/printk
7   4   1   7
[root@davids-devtest-f32 ~]# grep LOGLEVEL_DEFAULT 
/boot/config-5.8.14-200.fc32.x86_64
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
CONFIG_CONSOLE_LOGLEVEL_QUIET=3
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4

I see the same printk values and config settings in the 5.8.15-201.

I also don't see any tweaks to the kernel cmdline, so I'm also wondering what
else can be setting these values.


-- 
kind regards,

David Sommerseth
OpenVPN Inc
___
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

Kernel - default log levels

[David S.]

Hi,

I just spotted that there is a difference in the default log levels on
Fedora and RHEL-8 vs RHEL-7.

Fedora/RHEL-8 uses:

   # cat /proc/sys/kernel/printk
   7   4   1   7

while RHEL-7 uses:

   # cat /proc/sys/kernel/printk
   2   4   1   7

I also see that this seems to have been changed in the the packaging


   commit 4778b265ca87608cf8dcbcec31c0230555d98784
   Author: Justin M. Forbes 
   Date:   Tue Dec 13 16:26:04 2016 -0600

   Linux v4.9-2682-ge7aa8c2 (missing secure boot as that is being
   rebased to the new upstream tree

This is quite a while ago, but my googlefoo wasn't strong enough to find
a reason why.

I am not saying this necessarily it is wrong, it just makes the dmesg
contain more data.  So I am primarily curious why Fedora and RHEL-8 has
this high debug level as the default.

We're working on an OpenVPN Data Channel Offload kernel module where we
used this debug level to give more details for debugging  so a
default debug level of 7 prints out a lot more details which normal
production environments do not really need.   If this was a deliberate
change for a reason, we will reconsider how to enable debug logging
differently than using the printk debug levels.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




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: Looking for new Python package maintainers

[Pruthvi S Kumar]

Hey,

I am looking for packages to maintain and this would help a lot.

Thanks,
Pruthvi.

On Mon, Sep 7, 2020, 11:14 Dhanesh B. Sabane  wrote:

> Hello folks!
>
> I've been away from all Fedora activities for quite some time and I
> don't see a return anytime soon. There are 6 Python packages which are
> maintained by me and I'd like to hand them over. Following is the list
> of packages:
>
> https://src.fedoraproject.org/user/dhanesh95/projects
>
> Please let me know if anyone would like to take these up by replying to
> this email. I'll orphan all the packages that don't attract a
> maintainer till Sunday, 13th Sept 2020.
>
> Cheers!
>
> --
> Dhanesh B. Sabane
> https://dhanesh95.gitlab.io
> PGP ID: 0xB69A98C9C1642329
> Fingerprint: 9655 11F2 0D18 E76A 2396  D64D B69A 98C9 C164 2329
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Markus S.]

Why not Stratis?
___
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 btrfs the default file system for desktop variants

[Markus S.]

It's not a GPL violation. OpenZFS works under Linux through a compatibility 
layer called SPL, the Solaris Porting Layer. SPL is licensed under GPL. 
Torvalds himself said that a non-GPL file system that was written for another 
OS cannot be considered a derivative of the Linux kernel: 
https://yarchive.net/comp/linux/gpl_modules.html

SPL is a derived work from the Linux kernel because it's designed for the Linux 
kernel. SPL is therefore under GPL. ZFS is designed for Solaris and therefore a 
different license is fine.

Dell, a friggin huge US company, wouldn't distribute Ubuntu with their laptops 
if they as the distributor did something illegal.
___
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 btrfs the default file system for desktop variants

[Markus S.]

The legality FUD is unrelated to rolling or non-rolling kernels.
___
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 btrfs the default file system for desktop variants

[Markus S.]

OpenZFS is frequently lagging behind in support for newer kernels which would 
work against Fedora's "rolling" approach to kernel releases.

Proxmox and Ubuntu don't feature rolling kernel releases. That's why they can 
ship OpenZFS (without legal problems, btw).
___
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: Untouched BZ against cinnamon-desktop

[L S]

> Hi,
> 
> A long time ago I filled a BZ for F29 against the package group
> @cinnamon-desktop-environment. [1]
> Now I checked, and the issue still exists, so I re-opened it and moved
> against F32.
> 
> How can I get someone appropriate to notice it?
> The generic

Try assigning it to the right component.

>   "Assignee: Alternative GTK desktop environments"
> seems unresponsive.

I probably ignored it as it wasn't a cinnamon packaging issue.

> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1684764
> 
> --
> 
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
> 
> --
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Updating MUMPS/Sundials/PETSc

[David S]

On 4/7/20 12:51 PM, Antonio Trande wrote:

On 06/04/20 16:19, David Schwörer wrote:

On 4/5/20 6:06 PM, Antonio Trande wrote:

On 04/04/20 19:23, David S wrote:

On 4/4/20 4:38 PM, Antonio Trande wrote:

Hi all.

`MUMPS-5.3.0` [1] `PETSc-3.13.0` [2] and `Sundials-5.2.0` [3] are coming
on Rawhide; these updates will need rebuilds of dependent packages:


[:snip:]


Thanks a lot for updating PETSc, I know PETSc is quite challenging to
package.

I tried to build BOUT++ against PETSc, using pkg-config.
the pkg-config files are installed to petsc/ subdirectory, but it seems
the pc files are not adjusted for this.

Further, I have been using petsc --with superludist without issues, can
you tell why this was disabled, so I can test whether this was fixed in
the mean time?


`superludist` support is reactivated; please, test petsc-3.13.0 again:
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1328023/



In the PETSc.pc files, the $MPI_INCLUDE are not expanded, which also
doesn't happen at evaluation time:
pkg-config PETSc --cflags
-I$MPI_INCLUDE/petsc

which isn't further evaluated. I guess replacing the ' with " in the
spec should ensure it gets evaluated.

PETSc is injecting -L/usr/lib which will cause linking issues if there
is e.g. a libhdf5.so in /usr/lib because the MPI lib is needed.

Besides these two issues, everything seems to be fine.


Last build on Copr should fix these issues. Please, test it again:
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1329534/



Thanks, this works now for me.
Minor issue is the -L/usr/lib64/mpich/lib that might override a user 
choice. It isn't needed, as the mpi wrapper sets appropriate flags, but 
it doesn't cause any issues for me.


I found an issue, where linking against petsc (mpi version) and hdf5 
(serial version), this causes an error with unresolved dependencies for 
libpetsc.so

This is caused by petsc linking against the mpi hdf5, but I only had
hdf5-devel installed. Thus the linker selected the serial version.
Thus I needed to install the hdf5-{mpich,openmpi}-devel package if 
linking against petsc(mpi) and hdf5.
This was confusing for me, and there might be other libraries affected 
by this.

Maybe a
Requires: (hdf5-mpich-devel if hdf5-devel)
for the petsc-mpich-devel could help - but I am not sure about this one.
I am neither sure that this is sufficient, nor whether this is the right 
place to do this.


Thanks for getting this all fixed,
David
___
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: Updating MUMPS/Sundials/PETSc

[David S]

On 4/4/20 4:38 PM, Antonio Trande wrote:

Hi all.

`MUMPS-5.3.0` [1] `PETSc-3.13.0` [2] and `Sundials-5.2.0` [3] are coming
on Rawhide; these updates will need rebuilds of dependent packages:


[:snip:]


Thanks a lot for updating PETSc, I know PETSc is quite challenging to 
package.


I tried to build BOUT++ against PETSc, using pkg-config.
the pkg-config files are installed to petsc/ subdirectory, but it seems 
the pc files are not adjusted for this.


Further, I have been using petsc --with superludist without issues, can 
you tell why this was disabled, so I can test whether this was fixed in 
the mean time?


[1]
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1327044/
[2]
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1327319/
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=43020532


___
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

Orphaned package: cuneiform

[Dmitrij S. Kryzhevich]

Subj is an OCR system which needs to much love to be alive that I 
haven't. It's not required from any other package, it never had upstream 
from he very beginning and it is a `tesseract` OCR to switch to. So it's 
time to say good bye for me.


It would be nice if anybody could adopt it (but I do not believe this 
could ever happen).


See also: https://bugzilla.redhat.com/show_bug.cgi?id=1799265 and I 
believe there are no opened bugs.

Package page: https://src.fedoraproject.org/rpms/cuneiform

Regards,
Dmitrij
___
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

Port fedora for RISC-V with out compressed instructions

[Sreenadh S]

We want to port fedora for  RISC-V with out compressed (RV64IMAFD) instructions.

We are from Centre for Development of Advanced Computing (C-DAC) India.
We have implemented an Out-of order quad core RISC-V processor on FPGA.

The processor is without compressed instructions.
We want to port fedora for  RISC-V with out compressed instructions.

Please share the link if it is already ported, or give the guidelines on how to 
port.

Regards,

Sreenadh S.
___
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: Better interactivity in low-memory situations

[S.]

(Oops, sorry, re-post because I messed up the threading.)

I'm not a developer, nor do I pretend to understand the nuances of memory management. But 
I signed up for this list just to say "thanks" to all the devs and others that 
are finally discussing what I consider to be one of the biggest problems with Linux on 
the desktop.

My experience with desktop Linux distros with SSDs when a few processes start 
to leak memory, or if I launch a new program when my system is right at the 
limits, is a full system hang where only the mouse occasionally moves jerkily, 
and I can't switch to a virtual terminal. I recently learned the SysRq trick to 
evoke the OOM killer, but I personally think that the kernel should deal with 
that, not the user. As unfortunate as it is for the OOM killer to have to 
randomly kill something, I am of the opinion that the OS should *never* lock 
up, period. I would strongly prefer that one application get killed instead of 
losing all my applications and working data because of a necessary hard reboot.

I don't know if this helps or not, but anecdotally I started see this issue 
*after* SSDs became more common, i.e. I don't think I ever experienced it with 
spinning rust. Maybe something to do with the vastly faster I/O of an SSD, 
which allows it to more quickly saturate the RAM before the OOM killer has time 
to react?

Also, I've had relatively low memory KVM guests running on a VPS under very high load, 
and they never lockup. The OOM killer does occasionally kick in, but the affected daemon 
or systemd service restarts and it's amazingly undramatic. It appears that this issue 
only occurs with Xorg (and I imagine Wayland) and "desktop" usage.

As for the problem of the randomness of the OOM killer, couldn't it be made to 
take into account the PID and/or how long the process has been running? 
Normally Xorg (and I assume Wayland stuff) gets started before the other 
desktop programs that tend to consume a lot of memory. So if it's a higher PID 
and/or has been running for less time, give it a higher score for killability.

In my experience on a system with 8GB of RAM and an SSD, the amount of swap 
space makes no difference. I've tried with no swap space, with 2GB, with 8GB, 
etc, and it still hangs under high memory usage. I've also tried tuning a lot 
of sysctl parameters such as vm.swappiness, vm.vfs_cache_pressure, and 
vm.min_free_kbytes, to no avail.

Don't know if this helps, but here are some additional discussions of Linux 
unresponsiveness under low memory situations from a layman's perspective:
- osnews.com/story/130117/kde-usability-and-productivity-are-we-there-yet/ (in 
the comments)
- 
unix.stackexchange.com/questions/373312/oom-killer-doesnt-work-properly-leads-to-a-frozen-os
- bbs.archlinux.org/viewtopic.php?id=233843
- 
askubuntu.com/questions/432809/why-is-kswapd0-running-on-a-computer-with-no-swap/432827#432827
- 
unix.stackexchange.com/questions/24625/how-to-completely-disable-swap/24646#24646

Thanks again to everyone for looking into this!
___
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: Better interactivity in low-memory situations

[S.]

I'm not a developer, nor do I pretend to understand the nuances of memory management. But 
I signed up for this list just to say "thanks" to all the devs and others that 
are finally discussing what I consider to be one of the biggest problems with Linux on 
the desktop.

My experience with desktop Linux distros with SSDs when a few processes start 
to leak memory, or if I launch a new program when my system is right at the 
limits, is a full system hang where only the mouse occasionally moves jerkily, 
and I can't switch to a virtual terminal. I recently learned the SysRq trick to 
evoke the OOM killer, but I personally think that the kernel should deal with 
that, not the user. As unfortunate as it is for the OOM killer to have to 
randomly kill something, I am of the opinion that the OS should *never* lock 
up, period. I would strongly prefer that one application get killed instead of 
losing all my applications and working data because of a necessary hard reboot.

I don't know if this helps or not, but anecdotally I started see this issue 
*after* SSDs became more common, i.e. I don't think I ever experienced it with 
spinning rust. Maybe something to do with the vastly faster I/O of an SSD, 
which allows it to more quickly saturate the RAM before the OOM killer has time 
to react?

Also, I've had relatively low memory KVM guests running on a VPS under very high load, 
and they never lockup. The OOM killer does occasionally kick in, but the affected daemon 
or systemd service restarts and it's amazingly undramatic. It appears that this issue 
only occurs with Xorg (and I imagine Wayland) and "desktop" usage.

As for the problem of the randomness of the OOM killer, couldn't it be made to 
take into account the PID and/or how long the process has been running? 
Normally Xorg (and I assume Wayland stuff) gets started before the other 
desktop programs that tend to consume a lot of memory. So if it's a higher PID 
and/or has been running for less time, give it a higher score for killability.

In my experience on a system with 8GB of RAM and an SSD, the amount of swap 
space makes no difference. I've tried with no swap space, with 2GB, with 8GB, 
etc, and it still hangs under high memory usage. I've also tried tuning a lot 
of sysctl parameters such as vm.swappiness, vm.vfs_cache_pressure, and 
vm.min_free_kbytes, to no avail.

Don't know if this helps, but here are some additional discussions of Linux 
unresponsiveness under low memory situations from a layman's perspective:
- osnews.com/story/130117/kde-usability-and-productivity-are-we-there-yet/ (in 
the comments)
- 
unix.stackexchange.com/questions/373312/oom-killer-doesnt-work-properly-leads-to-a-frozen-os
- bbs.archlinux.org/viewtopic.php?id=233843
- 
askubuntu.com/questions/432809/why-is-kswapd0-running-on-a-computer-with-no-swap/432827#432827
- 
unix.stackexchange.com/questions/24625/how-to-completely-disable-swap/24646#24646

Thanks again to everyone for looking into this!
___
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

two builds stuck in pending testing for nine days

[Kaleb S. KEITHLEY]

f28: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e6538e58ce

and

f29: https://bodhi.fedoraproject.org/updates/FEDORA-2018-175284c10b

Is there a reason they haven't moved to testing state?

Thanks

--

Kaleb

___
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: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Kaleb S. KEITHLEY]

On 12/6/18 7:04 AM, Kaleb S. KEITHLEY wrote:

> 
>> And the other active maintainer (branto) and I don't have cycles to
>> devote to keeping (any part of) it building on 32-bit archs.
> 
> But people can always send patches. ;-)

If someone else would like to take over as maintainer, I'm happy to give
it up.

LMK.

--

Kaleb
___
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: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Kaleb S. KEITHLEY]

On 12/5/18 9:50 PM, Peter Robinson wrote:
> Kaleb,
> 
> Firstly the title is misleading as there was no heads up, a heads up
> is notice before you actually push the change, not when you do the
> change.

I suggest you take this up with branto. He's the one who built it
without 32-bit archs without any warning. I only found out about it when
I got build notices from koji (or pagure or whatever.)

You would have preferred no notice at all?

>> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl archs
>> starting in fedora-30/rawhide.
>>
>> The upstream project doesn't support it. The armv7hl builders don't have
>> enough memory (or address space) to build some components.
>>
>> And the other active maintainer (branto) and I don't have cycles to
^^
>> devote to keeping it building on 32-bit archs.
^
>>
>> (FWIW, currently ceph-12.2.9 (luminous) is in rawhide, f29, and f28 and
>> it has packages for i686 and armv7hl for people who want to run ceph on
>> 32-bit archs.)
> 
> As others have asked in the thread can we possibly build client only?

We?

Since the above seems to have been unclear:

> And the other active maintainer (branto) and I don't have cycles to
> devote to keeping (any part of) it building on 32-bit archs.

But people can always send patches. ;-)

--

Kaleb
___
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: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Kaleb S. KEITHLEY]

On 12/5/18 8:34 AM, Dan Horák wrote:
> On Wed, 5 Dec 2018 14:23:49 +0100
> Marcin Juszkiewicz  wrote:
> 
>> W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze:
>>
>>> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl
>>> archs starting in fedora-30/rawhide.
>>
>>> The upstream project doesn't support it. The armv7hl builders don't
>>> have enough memory (or address space) to build some components.
>>
>> BTW - how much memory is needed to build Ceph 14?

More — apparently — than the armv7hl builders have. :-) branto may know.

> have you tried building with reduced debuginfo, eg. -g1 or even -g0?

branto told me that he has tried all the different optimization levels.

> I wonder how much broken deps it will cause.

Don't know. Hence this heads up warning.

-- 

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

[HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Kaleb S. KEITHLEY]

Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl archs
starting in fedora-30/rawhide.

The upstream project doesn't support it. The armv7hl builders don't have
enough memory (or address space) to build some components.

And the other active maintainer (branto) and I don't have cycles to
devote to keeping it building on 32-bit archs.

(FWIW, currently ceph-12.2.9 (luminous) is in rawhide, f29, and f28 and
it has packages for i686 and armv7hl for people who want to run ceph on
32-bit archs.)

-- 

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

enabling KCM in the Fedora kernels

[Kaleb S. KEITHLEY]

Hi,

How would one go about requesting this be enabled by default?

Upstream NFS-Ganesha devs have been playing with it a bit and got a
modest performance boost.

It's conceivable that GlusterFS could utilize it too.

Thanks,

--

Kaleb
___
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/JSO5CKPO2GIDS77WLWHVVMRX7MJ5424S/

Re: [fesco] Updated FTBFS package policy

[Anoop C S]

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].
> 
> The updated policy is still at 
> https://fedoraproject.org/wiki/Fails_to_build_from_source.
> 
> Highlights:
> 
> - packages which FTBFS are subject to orphaning if there is no
>   maintainer acknowledgement within 8 weeks
> 
> - packages which FTBFS in two consecutive mass rebuilds will be
>   retired soon after the second mass rebuild
> 
> The implementation of this policy hinges on improving the releng
> scripts used to create and manage FTBFS bugs. There is approximately
> two months until the next use of those scripts, so I'm hopeful we'll
> get them working.
> 
> If your package wasn't successfully built for F28, please fix that!

As per the following bug report I did a scratch build for f29 and it passed 
successfully. What shall
I do with the FTBFS bug now?

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

> [1] https://pagure.io/fesco/issue/1890
> [2] https://pagure.io/fesco/issue/1877#comment-509161
> ___
> 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/P3KFTJMDNO42POS5N3Z4UXDNPFGAQH73/
___
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/CGYEZZMQ7G62WRBVWNT74A3EMGBGJFP6/

build failed on s390x, other archs building okay

[Kaleb S. KEITHLEY]

Is this a spurious failure or ???

...
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=28564187
...
buildArch (glusterfs-4.1.2-1.fc29.1.src.rpm, s390x): free -> FAILED:
Fault: 


thanks,

--

Kaleb
___
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/O2BNTIJT3KVZIZN4UO2JKSPXFOSTV6LI/

release-monitoring is telling me it has noticed (new) ceph-13.0.x

[Kaleb S. KEITHLEY]

according to https://release-monitoring.org/project/267/

But the Homepage: in the above and the Source: in the .spec would seem
to be saying that http://download.ceph.com/tarballs/ is where
the-new-hotness is looking.

And there is no ceph-13.x.y tar at that location (yet).

It's a maze of twisty passages. Or maybe at's a twisty maze of passages.
How do I find where release-monitoring is actually looking?

Thanks,

-- 

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

Re: 'endless' stream of "greenwave is a GO on glusterfs-4.0.0-2...." emails

[Kaleb S. KEITHLEY]

On 03/21/2018 04:45 PM, Kevin Fenzi wrote:
> On 03/20/2018 11:02 AM, Kaleb S. KEITHLEY wrote:
>>
>> I've rec'd about 30 of these in the last hour or so, fedora-28,
>> fedora-27, fedora-26, and fedora-28-modular.
>>
>> Would someone please make them stop
> 
> You can do so.

I think you misunderstood what I was asking.

I'm fine with getting _one_ notification. Or maybe even five.

But I have probably 50 in my inbox after all was said and done. All from
one build.


> 
> Go to:
> 
> https://apps.fedoraproject.org/notifications
> 
> login and select email
> 
> There should be a ruleset on the right called:
> "Events on packages I own"
> 
> Click on it to edit it.
> 
> On the right now there should be a long list of possible messages, one
> of them is "Greenwave decisions"
> 
> Click on "Greenwave decisions" and then "add this rule"
> 
> Now there should be a "Greenwave decisions" rule on the left in your
> ruleset.
> 
> Under that is a "!Negate" button. Click on that to make the rule be a
> negation rule instead of a matching rule.
> 
> Now you should no longer get any greenwave emails.
> 
> Sorry this is so confusing an interface. It really needs a re-write with
> input from some design folks, but we just haven't had the cycles to do
> so yet.
> 
> kevin
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

'endless' stream of "greenwave is a GO on glusterfs-4.0.0-2...." emails

[Kaleb S. KEITHLEY]

I've rec'd about 30 of these in the last hour or so, fedora-28,
fedora-27, fedora-26, and fedora-28-modular.

Would someone please make them stop

Thanks

--

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

Re: f28 and rawhide ignoring static ip settings

[Arnoldas S.]

On Thu, Mar 15, 2018 at 9:27 PM, Patrick マルタインアンドレアス Uiterwijk <
puiterw...@redhat.com> wrote:

> > On 03/15/2018 01:23 PM, Tomasz Torcz 👁️ wrote:
> >
> > It's not. Now it's enp0s3.
> >
> > And renaming /etc/sysconfig/network-scripts/ifcfg-ens3 to ifcfg-enp0s3
> > doesn't do anything.
>
> Note that the files themselves also contain a DEVICE= line that would need
> to be updated for it to apply again.
>
> Patrick
>

Hello. Mine is enp4s0.

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

Re: f28 and rawhide ignoring static ip settings

[Kaleb S. KEITHLEY]

On 03/15/2018 01:23 PM, Tomasz Torcz 👁️ wrote:
> On Thu, Mar 15, 2018 at 01:13:09PM -0400, Kaleb S. KEITHLEY wrote:
>>
>> Did I miss something?
>>
>> Both machines were dnf system-upgraded from f27. Static IP settings were
>> set at f27 install time and worked before the respective upgrades.
>>
>> f28 was working correctly until a couple of days ago to the best of my
>> knowledge.
>>
>> E.g.——
>>
>> %cat /etc/sysconfig/network-scripts/ifcfg-ens3
>> ...
>> IPADDR=192.168.122.26
>>
>> But it's getting 192.168.122.169 (from dhcp?)
> 
>   Could you double check if your interface is still called 'ens3'?
> There's a bug in latest systemd which breaks interface naming:
> https://github.com/systemd/systemd/issues/8446

It's not. Now it's enp0s3.

And renaming /etc/sysconfig/network-scripts/ifcfg-ens3 to ifcfg-enp0s3
doesn't do anything.

Thanks

--

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

f28 and rawhide ignoring static ip settings

[Kaleb S. KEITHLEY]

Did I miss something?

Both machines were dnf system-upgraded from f27. Static IP settings were
set at f27 install time and worked before the respective upgrades.

f28 was working correctly until a couple of days ago to the best of my
knowledge.

E.g.——

%cat /etc/sysconfig/network-scripts/ifcfg-ens3
...
BOOTPROTO=none
...
IPADDR=192.168.122.26
...

But it's getting 192.168.122.169 (from dhcp?)


Thanks

--

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

why do I keep getting Broken dependencies: nfs-ganesha emails

[Kaleb S. KEITHLEY]

E.g.:
...
On x86_64:
nfs-ganesha-2.6.0-0.4rc5.fc28.x86_64 requires
libntirpc.so.1.6(NTIRPC_1.6.0)(64bit)
...


I have long since built the GA packages: nfs-ganesha-2.6.0-1 in f28 and
even nfs-ganesha-2.6.0-2 because I didn't notice that this was whining
about -0.4rc5.

Is something stuck somewhere that it is complaining about this obsolete
build?

--

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

Re: LizardFS NFS Ganesha integration with no shared library available

[Kaleb S. KEITHLEY]

On 01/18/2018 01:16 PM, Kaleb S. KEITHLEY wrote:
> On 01/18/2018 03:23 AM, Jonathan Dieter wrote:
>> (This is meant for the Fedora devel mailing list, but I've cc'd the
>> nfs-ganesha mailing list in the hopes that they might see something I'm
>> missing)
>>
>> The latest release of the LizardFS distributed filesystem includes a
>> FSAL for NFS Ganesha, allowing you to mount a LizardFS filesystem using
>> NFS (or pNFS, if you prefer).
> 
> The LizardFS FSAL is GPLv3.  NFS-Ganesha is LGPLv3+.
> 
> From a Fedora packaging standpoint is it acceptable to build a GPLv3
> plug-in for an otherwise LGPLv3+ binary?
> 
> If the licenses were reversed, I'd be reasonably confident that that
> combination is okay.
> 
> What sayeth our "I'm not a lawyer but I play one on Fedora Devel mailing
> list" legal beagles?

And yes, I've already sent a query to a Real Lawyer™

-- 

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

Re: LizardFS NFS Ganesha integration with no shared library available

[Kaleb S. KEITHLEY]

On 01/18/2018 03:23 AM, Jonathan Dieter wrote:
> (This is meant for the Fedora devel mailing list, but I've cc'd the
> nfs-ganesha mailing list in the hopes that they might see something I'm
> missing)
> 
> The latest release of the LizardFS distributed filesystem includes a
> FSAL for NFS Ganesha, allowing you to mount a LizardFS filesystem using
> NFS (or pNFS, if you prefer).

The LizardFS FSAL is GPLv3.  NFS-Ganesha is LGPLv3+.

From a Fedora packaging standpoint is it acceptable to build a GPLv3
plug-in for an otherwise LGPLv3+ binary?

If the licenses were reversed, I'd be reasonably confident that that
combination is okay.

What sayeth our "I'm not a lawyer but I play one on Fedora Devel mailing
list" legal beagles?

Thanks

-- 

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

Re: LizardFS NFS Ganesha integration with no shared library available

[Kaleb S. KEITHLEY]

On 01/18/2018 03:23 AM, Jonathan Dieter wrote:
> (This is meant for the Fedora devel mailing list, but I've cc'd the
> nfs-ganesha mailing list in the hopes that they might see something I'm
> missing)
> 
> The latest release of the LizardFS distributed filesystem includes a
> FSAL for NFS Ganesha, allowing you to mount a LizardFS filesystem using
> NFS (or pNFS, if you prefer).
> 
> Unfortunately, NFS Ganesha doesn't provide a library to build the
> LizardFS FSAL against, so LizardFS upstream downloads the complete NFS
> Ganesha source and builds against that.
> 
> As far as I can see, all the other FSAL's are maintained and built in
> NFS Ganesha.
> 
> What is the best way for me to include NFS Ganesha support in LizardFS?
>1. Include the latest Fedora NFS Ganesha source and add a hard requires
>   to that version in the LizardFS NFS subpackage.
>2. Convince the LizardFS developers to try to move their FSAL into NFS
>   Ganesha? (LizardFS has just added a client library and doesn't have
>   a server library, so this will probably take some work)

That would be the path of least resistance. And the one I would suggest
and highly recommend. If they've already written a FSAL it should be
easy to add it to the nfs-ganesha source.

Depending on the license of course.


>3. Convince the NFS Ganesha developers to create a library that you can
>   compile FSAL's against?  (The last thread I saw in the NFS Ganesha
>   devel list on this subject was six years old)

That would be a non-trivial amount of work with little benefit to the
current FSAL developers.

It's not an unreasonable request, per se, but we have other, higher
priorities.

>4. ???
> 
> Any advice would be great, as I'd love to get this feature into
> Fedora's release of LizardFS.

Do you have a contact for someone at LizardFS?  I looked at their web
site and nothing popped out at me.

-- 

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

glusterfs in Fedora Modular 27?

[Kaleb S. KEITHLEY]

I've been contacted by Fedora QE about this, and have bz
https://bugzilla.redhat.com/show_bug.cgi?id=1518150

I haven't followed (can't follow) Fedora closely enough to know what's
needed here. Apparently none of my co-maintainers have either. ;-)

glusterfs packages are built for f27.

Reading through -devel it kinda looks like there was a branch created. A
branch that I should be doing builds on. But I have no branch in the
glusterfs dist-git other than the usual f26, f27, master that I could do
a build on.

Would someone hit me with a cluebat please? Was I supposed to request a
-module branch in dist-git?

Thanks,

--

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

sysconf(_SC_IOV_MAX) returns -1 in f27 and f28/rawhide (glibc-2.26-8)

[Kaleb S. KEITHLEY]

perusing the glibc source and headers it seems to come down to the
   #undef __IOV_MAX
line in bits/uio_lim.h.

The Changelog (2017-06-14) speaks rather obliquely to the issue, but I 
can't quite figure out if


  sysconf(_SC_IOV_MAX);

now returning -1 (errno = 0) is an unintentional side effect of the 
changes or not. (I don't follow glibc development to know what the 
history is behind this change.) In f26, glibc-2.25-10 it returns 1024.
Off hand I don't see any way that glibc could be built now to make the 
call return anything but -1.


Anyone know more of the story? Or want to venture a guess?

Thanks

--

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

Re: A less "bloated" KDE spin

[Markus S.]

Wholeheartedly agree. Everybody who disagrees with your proposal better put 
their money where their mouth is and do all necessary QA work for the upcoming 
release!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rdma -devel packages missing (?) on f27/armv7hl, builds failing

[Kaleb S. KEITHLEY]

switching to rdma-core-devel also fails.

because according to 
https://koji.fedoraproject.org/koji/buildinfo?buildID=953605 there are 
no armv7hl rpms built.


Probably due to the
  # 32-bit arm is missing required arch-specific memory barriers,
  ExcludeArch: %{arm}
in its .spec file

Which seems odd considering we've had IB/RDMA on armv7hl thus far. But 
if that's really the case then the solution is clear.


Also rdma-core hasn't been built for f28 yet!




On 08/22/2017 07:12 AM, Vít Ondruch wrote:



Dne 22.8.2017 v 12:48 Peter Robinson napsal(a):

On Tue, Aug 22, 2017 at 11:36 AM, Kaleb S. KEITHLEY  wrote:

I've built glusterfs previously on F27 with these same Build-Requires. Same
package & same .spec build on F28 and F26.

While trying to build a new version for the last 24 hours I keep hitting
this:

...
DEBUG util.py:439:  No matching package to install: 'libibverbs-devel'
DEBUG util.py:439:  No matching package to install: 'librdmacm-devel >=
1.0.15'

For some reason the owner in f27 tag was switched to releng and then
has been blocked:

Sat Aug 19 03:43:40 2017 package list entry for librdmacm in
module-package-list updated by pkgdb
 owner.name: dledford -> releng
Sat Aug 19 06:20:14 2017 librdmacm-1.1.0-4.fc26 untagged from f27 by releng
Sat Aug 19 06:20:14 2017 librdmacm-1.1.0-6.fc27 untagged from f27 by releng
Sat Aug 19 06:20:31 2017 package list entry for librdmacm in f27
updated by releng
 blocked: False -> True

Sat Aug 19 06:20:17 2017 libibverbs-1.2.1-4.fc26 untagged from f27 by releng
Sat Aug 19 06:20:17 2017 libibverbs-1.2.1-6.fc27 untagged from f27 by releng
Sat Aug 19 06:20:31 2017 package list entry for libibverbs in f27
updated by releng
 blocked: False -> True

I'm not sure why that is because it wasn't blocked for f28 because
both of those packages look to be replaced by rdma-core looking at one
of the commit logs

https://src.fedoraproject.org/rpms/libibverbs/c/bd306d2c33fadaf21dafb1351730a0c59052aed1?branch=master

It looks like the maintainer or the person that retired those packages
hasn't added the proper retires/provides into the rdma-core* packages
to ensure the upgrade path is smooth.


See the other thread:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WJHXQ3G6H7UMVERDCMUXBYDJTFABTGW3/

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


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

rdma -devel packages missing (?) on f27/armv7hl, builds failing

[Kaleb S. KEITHLEY]

I've built glusterfs previously on F27 with these same Build-Requires. 
Same package & same .spec build on F28 and F26.


While trying to build a new version for the last 24 hours I keep hitting 
this:


...
DEBUG util.py:439:  No matching package to install: 'libibverbs-devel'
DEBUG util.py:439:  No matching package to install: 'librdmacm-devel >= 
1.0.15'

...

Thanks,

--

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

librpm.so.7, deltarpm-3.6.{21,22} and building ceph on rawhide

[Kaleb S. KEITHLEY]

After a successful scratch build[1] on fc27/i686 of ceph-2.1.2-2 to test 
a fix for a 32-bit issue I immediately fired off a full fedpkg build, 
which failed thusly [2]:


...
DEBUG util.py:439:  Error: nothing provides librpm.so.7()(64bit) needed 
by deltarpm-3.6-22.fc27.x86_64
DEBUG util.py:439:  (try to add '--allowerasing' to command line to 
replace conflicting packages)

...

the scratch build had rpm-4.13.0.1-41.fc27 and deltarpm-3.6-21.fc27

The fedpkg builds got rpm-4.13.90-0.git14002.1.fc27 and 
deltarpm-3.6-22.fc27  (x86_64 at least, I didn't look at the others)


Did I just catch things in an temporarily inconsistent state? I only 
noticed the warning that rpm-4.14 is coming soon.


Thanks,

--

Kaleb

[1] https://kojipkgs.fedoraproject.org//work/tasks/1690/21151690/root.log
[2] https://kojipkgs.fedoraproject.org//work/tasks/3722/21153722/root.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppc64le build failure, does it look familiar?

[Kaleb S. KEITHLEY]

More ceph-12.1.1

This has built successfully previously, including the recent mass
rebuild. Today the other associated builds have either finished or
passed this point, but on the ppc64le build today I got this:

...
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb
--target ppc64le --nodeps /builddir/build/SPECS/ceph.spec'] with env
{'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf
"\\033]0;\\007"', 'HOME': '/builddir', 'HOSTNAME': 'mock',
'PS1': ' \\s-\\v\\$ ', 'LANG': 'en_US.UTF-8', 'TERM':
'vt100', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'} and shell False
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/ps: error while loading shared libraries: /lib64/librt.so.1:
expected localentry:0 `pthread_attr_setdetachstate'
/usr/bin/basename: missing operand
Try '/usr/bin/basename --help' for more information.
Building target platforms: ppc64le
...

Full build log at
https://kojipkgs.fedoraproject.org//work/tasks/6424/20856424/build.log

Look familiar to anyone?

Thanks,

-- 

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

Re: armv7hl builds running out of memory

[Kaleb S. KEITHLEY]

On 07/26/2017 06:25 PM, Al Stone wrote:

I've been experimenting in a slightly different environment (RHEL vs Fedora) but have been seeing oddly 
similar results.  The use or not of the "-pipe" in GCC didn't seem to help.  If I forced the make 
in the %build step to be just "make" (aka, "make -j1"), I could always get a build to 
work, albeit slowly.

It turns out there is a typo in the spec file; look for the string "WTIH_BABELTRACE" -- that should be 
"WITH_BABELTRACE".  In the environment I'm using, "make -j32" is the default state.  If I leave the 
typo alone and do not change the "make -j32", I can pretty consistently get the ceph build to fail; the 
failure moves around a bit but generally seems to hang around with where the babeltrace headers are being used 
(somewhere in RBD code, usually).  If I fix the typo -- and change nothing else -- the build succeeds.

Would you mind trying this one change -- fixing the typo *only* -- and see if 
you get the same results?


If by same result you mean the build still fails, then yes. I get the 
same result.


It's still running out of memory. Not the same way as the prior builds 
though.


...
[100%] Building CXX object src/rgw/CMakeFiles/radosgw.dir/rgw_main.cc.o
/usr/include/c++/7/bits/stl_map.h: In static member function 'static 
void 
pg_missing_set::generate_test_instances(std::__cxx11::list*>&) 
[with bool TrackChanges = false]':
/usr/include/c++/7/bits/stl_map.h:493:4: note: parameter passing for 
argument of type 'std::_Rb_treepg_missing_item>, std::_Select1stpg_missing_item> >, std::less, std::allocatorhobject_t, pg_missing_item> > >::const_iterator {aka 
std::_Rb_tree_const_iterator 
>}' changed in GCC 7.1

__i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
^~~
virtual memory exhausted: Operation not permitted
...
make: *** [Makefile:141: all] Error 2
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.RgosXb (%build)
Bad exit status from /var/tmp/rpm-tmp.RgosXb (%build)
Child return code was: 1
...

See https://koji.fedoraproject.org/koji/taskinfo?taskID=20797264 for 
full logs.


--

Kaleb


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

Re: armv7hl builds running out of memory

[Kaleb S. KEITHLEY]

On 07/26/2017 08:22 AM, Björn 'besser82' Esser wrote:


It looks like the whole parallelized make-process is hitting the 4 
Gbytes limit per process / task on 32 Bit arches…


Have you tried this?

%build
export CFLAGS="echo %{optflags} | sed -e 's!-pipe!!g'"
export CXXFLAGS="$CFLAGS"
…

Sometimes piping from cpp to gcc to as to ld takes too much memory on 32 
Bit arches…


Unfortunately that didn't help.

FWIW the actual edits to the ceph.spec that I used (since ceph uses 
cmake and other factors):


...
export RPM_OPT_FLAGS=`echo $RPM_OPT_FLAGS | sed -e 's/i386/i486/' -e 
's/-pipe//g'`


export CPPFLAGS="$java_inc"
export CFLAGS="$RPM_OPT_FLAGS"
export CXXFLAGS="$RPM_OPT_FLAGS"
export LDFLAGS=`echo $LDFLAGS | sed -e 's/-pipe//g'`
...

--

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

armv7hl builds running out of memory

[Kaleb S. KEITHLEY]

trying to build ceph-12 on f27 armv7hl.

It builds on everything x86_64, aarch64, s390x, and i686 (w/o java), but
on armv7hl the build fails, reporting out of memory.

...
[100%] Built target ceph-osd
cc1plus: out of memory allocating 11284160 bytes after a total of
58859520 bytes
make[2]: *** [src/CMakeFiles/ceph-dencoder.dir/build.make:64:
src/CMakeFiles/ceph-dencoder.dir/test/encoding/ceph_dencoder.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1626:
src/CMakeFiles/ceph-dencoder.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
...


full log at
https://kojipkgs.fedoraproject.org//work/tasks/4038/20724038/build.log

Is there any way to bump up swap on the builders? Or any trick to get
more memory or run on a particular machine that has more memory?

Thanks


-- 

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

Do I need to do a Self Contained Change to update Ceph to Ceph 12 in fedora-27?

[Kaleb S. KEITHLEY]

The current version is quite old (10.2.7) and I believe that may have 
been built before f27/rawhide was updated to gcc-7.


10.2.8, 10.2.9, and 11.x.y do not build due to internal compiler errors.

12.1.1 does build at this time [1].

I am the package owner.

Thanks,

[1] https://kojipkgs.fedoraproject.org//work/tasks/1128/20631128/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Kaleb S. KEITHLEY]

You keep using that word — where for [sic] — I do not think it means 
what you think it means. (As inconceivable as it may seem.)


--

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

HEADSUP: Soname bump for Libharu

[Dmitrij S. Kryzhevich]

I'm updating libharu for rawhide and there was a soname change. I 
believe affected packages are:


EMBOSS
libeplplot
mathgl (my one)
perl-PDF-Haru
saga
wt

Old API should work.

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

fedpkg update is failing

[Kaleb S. KEITHLEY]

TL;DNR 
https://paste.fedoraproject.org/paste/PyG9sLWVgPpVKqAXPYp6K15M1UNdIGYhyRLivL9gydE=/


Reader's Digest version: Could not execute update: Could not generate 
update request: Command 'bodhi --bodhi-url 
https://bodhi.fedoraproject.org/ --new --release f26 --file 
bodhi.template libntirpc-1.4.4-1.fc26 --username kkeithle' returned 
non-zero exit status 255


This is on up to date f25.

I am authenticated with kinit kkeit...@fedoraproject.org

Any ideas?

Thanks,

--

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

Ridicules bug with imake

[Dmitrij S. Kryzhevich]

Hi,

I have a ridicules bug with imake[1]. Could anybody help here?

Dmitrij


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1429343
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Something wrong with imake on ppc

[Dmitrij S. Kryzhevich]

Hi,

I have this rasmol f26 build [1] where all non-ppc arch are ended 
correctly. In logs I see that imake in ppc* have some strange issues 
with macros expanding which it has not on other platforms. It should be 
noted that on f24 and f25 and epel7 releases everything was fine.


And here is a log:

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.IiL9hb
+ umask 022
+ cd /builddir/build/BUILD
+ cd RasMol-2.7.5.2
+ pushd src
~/build/BUILD/RasMol-2.7.5.2/src ~/build/BUILD/RasMol-2.7.5.2
+ ./rasmol_build_options.sh --pixeldepth=32 --use_gtk
+ xmkmf
imake -DUseInstalled -I/usr/share/X11/config
In file included from /usr/share/X11/config/Imake.tmpl:2194:0,
 from Imakefile.c:34:
/tmp/IIf.WrvsH0:301:0: error: detected recursion whilst expanding macro "vector"
multiple.h multiple.c vector.h vector.c \
 
/tmp/IIf.WrvsH0:301:0: error: detected recursion whilst expanding macro "vector"

/tmp/IIf.WrvsH0:309:0: error: detected recursion whilst expanding macro "vector"
multiple.o vector.o wbrotate.o langsel_unix.o maps.o $(GUIOBJ)
 
imake: Exit code 1.

  Stop.
error: Bad exit status from /var/tmp/rpm-tmp.IiL9hb (%build)

The question is simple: what wrong here?

Dmitrij

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=17788988
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Verification] FOSDEM speakers

[Alberto Rodriguez S]

Hello Everybody,

The list will be published on the Fedora Magazine and the community
today, 8:00 UTC and 7:00 UTC respectively,

Many thanks for the help :)

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

Re: Unretiring itpp

[Dmitrij S. Kryzhevich]

Hi, my two pence.



BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)


Not required.


%cmake -DBLA_VENDOR=ATLAS -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
make %{?_smp_mflags}


May be you want to do:
mkdir -p %{_target_platform}
pushd %{_target_platform}
%cmake -DBLA_VENDOR=ATLAS -DCMAKE_BUILD_TYPE=Release ..
popd
make -C %{_target_platform} %{?_smp_mflags}

and later

make -C %{_target_platform} install DESTDIR=$RPM_BUILD_ROOT


mv $RPM_BUILD_ROOT/usr/lib $RPM_BUILD_ROOT/%{_libdir}


That wouldn't work on systems with /usr/lib dir.
Anyway lib_64_ must be handled in another way.

You are missing %doc and %licence in %files still.

Dmitrij


Is this version better ? I think I incorporated all your suggestions +
some more that are in the same vein to what you suggested.

Theo.


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

Is there something wrong with the Koji builders?

[Kaleb S. KEITHLEY]

I've done two builds for rawhide this morning.

On the first the armv7hl and ppc64le builds failed because the source
tar file could not be unpacked.

On the second the aarch64 build failed because the source tar file could
not be unpacked.

All the other arches built successfully.

-- 

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

two package reviews

[Kaleb S. KEITHLEY]

Hi,

I have two packages up for review that could use some attention please:

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

and

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

Thanks,

-- 

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

Re: Packagers - Flag day 2016 Important changes

[Dmitrij S. Kryzhevich]

Well. Somehow it works now.


12.12.2016 09:08, Dmitrij S. Kryzhevich пишет:



* koji and the source lookaside were changed to use kerberos
authentication
instead of ssl certificates. All maintainers will need to:

kinit your-fas-accountn...@fedoraaproject.org


$ kinit kr...@fedoraproject.org
kinit: Client 'kr...@fedoraproject.org' not found in Kerberos database 
while getting initial credentials


Any clues?

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


--
К.ф.-м.н. ЛККМ ИФПМ СО РАН
Крыжевич Д.С.
tel.: +7-3822-286-973
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Dmitrij S. Kryzhevich]

Here is debug info:

$ KRB5_TRACE=/dev/stdout  kinit kr...@fedoraproject.org
[14820] 1481508960.831584: Getting initial credentials for 
kr...@fedoraproject.org

[14820] 1481508960.831767: Sending request (196 bytes) to FEDORAPROJECT.org
[14820] 1481508960.834886: Resolving hostname id.fedoraproject.org.
[14820] 1481508960.932073: Initiating TCP connection to stream 
152.19.134.198:1088

[14820] 1481508961.156915: Sending TCP request to stream 152.19.134.198:1088
[14820] 1481508961.550534: Received answer (188 bytes) from stream 
152.19.134.198:1088
[14820] 1481508961.550550: Terminating TCP connection to stream 
152.19.134.198:1088

[14820] 1481508961.552330: Response was not from master KDC
[14820] 1481508961.552360: Received error from KDC: -1765328378/Client 
not found in Kerberos database

[14820] 1481508961.552379: Retrying AS request with master KDC
[14820] 1481508961.552386: Getting initial credentials for 
kr...@fedoraproject.org
[14820] 1481508961.552441: Sending request (196 bytes) to 
FEDORAPROJECT.org (master)
kinit: Client 'kr...@fedoraproject.org' not found in Kerberos database 
while getting initial credentials

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

Re: Packagers - Flag day 2016 Important changes

[Dmitrij S. Kryzhevich]

* koji and the source lookaside were changed to use kerberos
authentication
instead of ssl certificates. All maintainers will need to:

kinit your-fas-accountn...@fedoraaproject.org


$ kinit kr...@fedoraproject.org
kinit: Client 'kr...@fedoraproject.org' not found in Kerberos database 
while getting initial credentials


Any clues?

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

Re: sudo not looking into /usr/local

[Anoop C S]

On Tue, 2016-11-15 at 18:42 +, Samuel Rakitničan wrote:
> Hi,
> 
> Something I stumbled upon today is that there is no convenient way by default 
> to make some custom
> script accessible via sudo without specifying full path.

What about -E option?

> Found out that sudo have limited set of paths in its environment that is 
> looking into [1]. Sadly,
> none of it is appropriate for custom scripts. I think it would be nice to 
> include /usr/local/bin
> and /usr/local/sbin also.
> 
> [1] http://unix.stackexchange.com/a/8652
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide vs koji f26 builds

[Kaleb S. KEITHLEY]

On 10/12/2016 08:58 AM, Kalev Lember wrote:

On 10/12/2016 02:47 PM, Kaleb S. KEITHLEY wrote:

Hi,

I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds


https://koji.fedoraproject.org/koji/getfile?taskID=16059122&name=build.log&offset=-4000


Yesterday (11 October) I downloaded and installed the current rawhide
and built — successfully — from the same src.rpm that's failing in koji.

I tried again today and the koji f26 build is still failing.

The koji f26 build of the previous release of glusterfs (3.7.15,
containing the same code) built fine approx five weeks ago.

What's the recommend action here, just wait a few days? Or something else?


From the log:

keys.c:121:11: error: storage size of 'hctx' isn't known
  HMAC_CTX hctx;
   ^~~~

Probably needs patching for openssl 1.1 that just landed in rawhide.



Sure, but I just installed a rawhide box from 
Fedora-Server-netinst-x86_64-Rawhide-20161010.n.0.iso and it still has 
openssl-1.0.2j-1.fc26.x86_64 and a `dnf update openssl` is not giving me 
anything newer.


I guess I can go get 
Fedora-Server-netinst-x86_64-Rawhide-20161011.n.0.iso or install the 
rpms from http://koji.fedoraproject.org/koji/buildinfo?buildID=809049.


--

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

Re: rawhide vs koji f26 builds

[Kaleb S. KEITHLEY]

On 10/12/2016 08:49 AM, Peter Robinson wrote:

On Wed, Oct 12, 2016 at 1:47 PM, Kaleb S. KEITHLEY  wrote:

Hi,

I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds


https://koji.fedoraproject.org/koji/getfile?taskID=16059122&name=build.log&offset=-4000


Can you reference the root task, can''t get that from the link above
so it's hard to tell all the details with just a snippet.




http://koji.fedoraproject.org/koji/taskinfo?taskID=16059121





Yesterday (11 October) I downloaded and installed the current rawhide and
built — successfully — from the same src.rpm that's failing in koji.

I tried again today and the koji f26 build is still failing.

The koji f26 build of the previous release of glusterfs (3.7.15, containing
the same code) built fine approx five weeks ago.

What's the recommend action here, just wait a few days? Or something else?

Thanks,

--

Kaleb



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

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


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

rawhide vs koji f26 builds

[Kaleb S. KEITHLEY]

Hi,

I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds


https://koji.fedoraproject.org/koji/getfile?taskID=16059122&name=build.log&offset=-4000

Yesterday (11 October) I downloaded and installed the current rawhide 
and built — successfully — from the same src.rpm that's failing in koji.


I tried again today and the koji f26 build is still failing.

The koji f26 build of the previous release of glusterfs (3.7.15, 
containing the same code) built fine approx five weeks ago.


What's the recommend action here, just wait a few days? Or something else?

Thanks,

--

Kaleb



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

Kernel 4.5 breaks upower

[Leslie S Satenstein]

I have multiple Linux distributions on my desktop.  upower works with F23 to 
show the UPS, 
but fails with F24.  There are two bugreports out for this problem. It does not 
appear thatupower v 99.4 or earlier is the problem.refer to 
http://www.spinics.net/lists/fedora-devel/msg220418.html

and to 
 
 [Bug 1342533] (Fedora) No UPS driver -- can' t detect status of UPS Battery
  Regards 
Leslie
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unannounced soname bump - userspace-rcu

[Anoop C S]

On Wed, 2016-06-22 at 16:40 +0200, Vít Ondruch wrote:
> 
> Dne 22.6.2016 v 16:21 Richard W.M. Jones napsal(a):
> > 
> > On Wed, Jun 22, 2016 at 03:03:09PM +0200, Vít Ondruch wrote:
> > > 
> > > It seems there was unannounced soname bump in userspace-rcu. Not
> > > sure
> > > what everything needs to get rebuild, but it seems that lttng-ust 
> > > at
> > > minimum (and there is already rhbz#1348895).
> > Ah, I see.  Maybe the bug component should be changed to
> > userspace-rcu?
> I'd say that lttng-ust component is the right component, although
> there
> might be more breakages ...
> 
> > 
> > 
> > Anyhow, this breaks my Koji builds at the moment.
> I was alerted by Koschei about this issue, since it can't resolve
> dependencies of vagrant-libvirt. I guess your dependency chain will
> be
> similar ;)
> 

Same here.. Got a notification yesterday regarding a failure from
Koschei for one of my packages due to some dependency issue with shared
library name change for userspace-rcu. But later I was notified that
all things are back to normal.

> Vít
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
> .org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

enable ABRT reports for glusterfs

[Kaleb S. KEITHLEY]

Hi,

My search engine fu is failing atm.

I get ABRT reports from notificati...@fedoraproject.org for another
package (nfs-ganesha) that I'm the maintainer for.

I'd like to enable ABRT reports for glusterfs. But I can't seem to find
where to do that.  Or maybe glusterfs never crashes!

Thanks,

-- 

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[Dmitrij S. Kryzhevich]

On Mon, Apr 18, 2016 at 6:02 PM, Alexander Ploumistos
 wrote:

Well, after almost three hours, fedora-review came through.

I am a little confused by the beginning of the %install section, could you
please explain the syntax of the first line?
(%make_install INSTALL="install -p")



It essentially expands out to:
%{__make} install DESTDIR=%{buildroot} INSTALL="install -p"

Previously, it was set to `make install INSTALL="install -p"
DESTDIR=%{buildroot}`, which is essentially the same thing. I just
chose to use the %make_install macro to be consistent with my usage of
%make_build (which is `%{__make} %{?_smp_mflags}`).




I'm sorry but may be the corresponding Bugzilla ticket is a better place 
for this conversation?


Dmitrij S. Kryzhevich
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Running CLI uitilities not available in Fedora?

[Dmitrij S. Kryzhevich]

Hello All!
I'd like to ask you for advice. I've packaged an application which can
use external CLI tools (not available in Fedora for various non-legal
reasons). Shall I remove support for these tools or better keep it?



Hello,

if your application has a preference for that CLI name modification and 
proper error handling you could just change reference to some note. I.e. 
"this_tool_name_NAME_is_not_installed", that should appear in error box. 
Or may be you'l submit a request to upstream to make this possible.


Dmitrij
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Running CLI uitilities not available in Fedora?

[Ryan S. Brown]

On 03/02/2016 06:50 AM, Peter Lemenkov wrote:

Hello All!
I'd like to ask you for advice. I've packaged an application which can
use external CLI tools (not available in Fedora for various non-legal
reasons). Shall I remove support for these tools or better keep it?


The answer is "it depends".

I don't think removing support/features from tools you package is the 
way forward: it makes maintenance harder for you, and if users install 
the non-available CLI then try to use your packaged program, they would 
be surprised to find it can't use that external CLI tool.


Definitely make sure that your packaged app has a useful error when 
users try to use features that require the external CLI, and maybe even 
tells them where to find it if they're willing to install from external 
sources.


-Ryan

--
Ryan Brown / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Notification of new version

[Dmitrij S. Kryzhevich]

Was a bugzilla ticket created? If not, perhaps it was recently added to
release-monitoring.org , it seems that's
the only version detected at this point:

https://release-monitoring.org/project/9781/

Thanks,
Richard


Thanks. Looks like it is a case.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Notification of new version

[Dmitrij S. Kryzhevich]

Hi,

I'd received a notification about new version released:

A new version of "rasmol" has been detected:  "2.7.5", packaged as "rasmol"


But current version is:
# rpm -q rasmol
rasmol-2.7.5.2-5.fc23.x86_64
 ^

What had gone wrong here?

Dmitrij
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: three questions: f24 branch, python3 default, where to put /etc/rsyslog.d/gluster.conf.example

[Kaleb S. KEITHLEY]

On 02/24/2016 10:46 AM, Orion Poplawski wrote:
> On 02/24/2016 07:17 AM, Kaleb S. KEITHLEY wrote:
>> Hi,
>>
>> 1) usually after the branch I build new packages for rawhide (i.e.
>> $branch+1). But atm in the master branch, a `fedpkg build` gives me
>>
>> Could not execute build: Package glusterfs-3.7.8-1.fc24 has already
>> been built
>>
>> Am I just too early? Or is there something missing that's preventing
>> builds for f25.
> 
> Did you do a git pull to bring down the new f24 branch?  I think that is what
> fedpkg keys off of.
> 

Yes. I'm not a git expert by any means, but I do know that much. ;-)

-- 

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: three questions: f24 branch, python3 default, where to put /etc/rsyslog.d/gluster.conf.example

[Kaleb S. KEITHLEY]

On 02/24/2016 09:45 AM, Stephen Gallagher wrote:
> On 02/24/2016 09:30 AM, Peter Robinson wrote:
>>> 1) usually after the branch I build new packages for rawhide (i.e.
>>> $branch+1). But atm in the master branch, a `fedpkg build` gives me
>>>
>>>  Could not execute build: Package glusterfs-3.7.8-1.fc24 has already
>>> been built
>>>
>>> Am I just too early? Or is there something missing that's preventing
>>> builds for f25.
>>
>> The branching is ongoing, there was infrastructure issues last night
>> so it's taken a bit longer than planned.
>>
>>> 2) Despite several articles out in the wild claiming that {F22,F23,F24}
>>> will switch to Python3 as the default, [1] would seem to indicate that
>>> the only thing we're going to see is 1) the update of Python3 from 3.4
>>> to 3.5, and 2) Python3 system-python and system-python-libs will be
>>> split out; however the default python will remain Python2.
>>>
>>> Is that correct?
>>
>> Not really, py3 is the default by means of being the only python
>> shipped in a number of Fedora deliverables but there's also some that
>> can't move directly to pure python3 yet due to other issues (like
>> ansible only bein py2 at the moment). So it's a "it depends" answer.
> 
> 
> To supplement this, it's the default in the sense that packagers are
> expected to ship python3 packages if they are supported upstream and if
> the package includes the same binary executable name for py2 and py3,
> only the py3 package should ship it.

I guess I don't really grok what that means. And/or I didn't frame my
question very well.

I installed a fresh rawhide Fedora/Server two days ago.

It has both python-2.7.11-4.fc24.x86_64 and python3-3.5.1-4.fc24.x86_64.
 /usr/bin/python is a symlink to python2.

Under what circumstances will /usr/bin/python be Python3?

Thanks

-- 

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

three questions: f24 branch, python3 default, where to put /etc/rsyslog.d/gluster.conf.example

[Kaleb S. KEITHLEY]

Hi,

1) usually after the branch I build new packages for rawhide (i.e.
$branch+1). But atm in the master branch, a `fedpkg build` gives me

Could not execute build: Package glusterfs-3.7.8-1.fc24 has already
been built

Am I just too early? Or is there something missing that's preventing
builds for f25.


2) Despite several articles out in the wild claiming that {F22,F23,F24}
will switch to Python3 as the default, [1] would seem to indicate that
the only thing we're going to see is 1) the update of Python3 from 3.4
to 3.5, and 2) Python3 system-python and system-python-libs will be
split out; however the default python will remain Python2.

Is that correct?


3) The Fedora and upstream glusterfs.spec file package example rsyslog
config files for some distributions. (Although since Fedora hasn't used
rsyslog by default since F20 or so, these aren't actually installed on
recent Fedora releases.) The packaging guidelines don't appear to say
anything on the topic. Absent anything in the packaging guidelines, is
there a consensus for where they should be installed on systems that do
use rsyslog, e.g. EPEL/EL6?

In /etc/rsyslog.d/glusterfs.conf.example? Or somewhere else, e.g.
/usr/share/doc/glusterfs/rsyslog.d/glusterfs.conf.example?


[1] https://fedoraproject.org/wiki/Releases/24/ChangeSet

Thanks,

-- 

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Ryan S. Brown]

On 02/22/2016 05:34 PM, Stephen John Smoogen wrote:

On 22 February 2016 at 13:00, Ralf Senderek  wrote:



The Fedora team could get a profile and verify the key(s) through
github, the Fedora and Red Hat web sites, the Fedora magazine twitter
account, and by having the Fedora team all sign publicly.


Every little helps. The important step would be if the Fedora devs state the
fingerprints in a visible way that risks their good reputation if the 
information
turned out to be incorrect. These statements would then be the foundation of
trust in what the Fedora 24 key signs.



OK and how many people check to see what another person's reputation
is? And how many people have had gotten bad reputations from signing
bad things? It all sounds great on paper, but without actual methods
and regular checks.. it is as useless as a keysigning party where no
one does a full check of the passport and driver's license with the
issueing authority. [We all do the $200.00 background check on
everyone we sign don't we?]


I don't, but I think there's benefit in using keybase.io and having any 
Fedora contributors verify that, because:


1. Keybase is easy to check - pop open the web page and it's all there
2. Hosted outside Fedora infrastructure, so 2 points of compromise would 
have to happen



Also, keep in mind that the checks on keybase aren't necessarily "you 
are Ryan Scott Brown, as identified by driver's license," but rather 
that I am the @ryan_sb on twitter, and ryansb on github, and owner of 
rsb.io. For most "people on the internet" the second set of parameters 
is what people actually know me as, so that's more useful for the looser 
verification of "someone I think would notice if Fedora switched their 
GPG key"


Also, tying the GPG key to the various Fedora project social accounts 
would help since, again, that's another point of compromise that would 
need to happen to switch up our .iso's.


Literally nothing we can ever do will be bulletproof[1], but doing 
anything better than putting the GPG keys on the same site as the ISOs 
isn't futile.



1: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf


Combined with having the key on getfedora.org, it at least provides a
measure of protection against our site being compromised. It also has
the benefit of, if someone knows of any Fedora devs on Twitter or
another service, they can follow the web of social-service trust. This
isn't as good as if they had a direct path to the Fedora WoT through
normal signatures, but it's much more likely to actually occur.


Yes all of this, please.


--
Ryan Brown / Senior Software Engineer, OpenStack / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Ryan S. Brown]

On 02/22/2016 02:22 PM, Ralf Senderek wrote:



If the site is compromised, most bets are off sadly.


Yes, for people who look only in one place, the manipulated web server.
But that is the reason why the fingerprint has to pop up in different places
where it is hard to fake. Even if this one user can be tricked, others can
discover that the site is compromised if the fingerprint is independently 
recorded
many times elsewhere.

BTW, pointing to a key server is not the way to convince anyone. A key server
is a convenient way to get keys, not a tool to assure their authenticity.
So I don't think that there is much of an alternative other than someone 
stepping in
and provide some first-hand knowledge about the key.


Could an external service such as keybase.io be helpful here? It's not a 
FOSS service, but it's been doing good work on making GPG more 
accessible by tying into many services and putting them all in a sort of 
verification dashboard.


If keybase is new to you, here's my profile https://keybase.io/ryansb

The Fedora team could get a profile and verify the key(s) through 
github, the Fedora and Red Hat web sites, the Fedora magazine twitter 
account, and by having the Fedora team all sign publicly.


Combined with having the key on getfedora.org, it at least provides a 
measure of protection against our site being compromised. It also has 
the benefit of, if someone knows of any Fedora devs on Twitter or 
another service, they can follow the web of social-service trust. This 
isn't as good as if they had a direct path to the Fedora WoT through 
normal signatures, but it's much more likely to actually occur.


--
Ryan Brown / Senior Software Engineer, OpenStack / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: requesting help on fixing gcc-6 FTBFS

[Dmitrij S. Kryzhevich]

Hi!

> 1/ Labplot - https://bugzilla.redhat.com/show_bug.cgi?id=1307279
>
> I think the issue is here -
>
> /builddir/build/BUILD/labplot-kf5-2.1.0/src/backend/worksheet/TextLabel.
> cpp:538:38:
> error: call of overloaded 'abs(qreal)' is ambiguous
>if (abs(point.x()-position.point.x())>20 &&
> qAbs(point.y()-position.point.y())>20 ) {
>
> There is mention about this in gcc 6 porting "guide" -
> https://gcc.gnu.org/gcc-6/porting_to.html
>
> But, I have no idea how to fix this.

May you could try to change abs to fabs (or alternatives)?
Otherwise, explicit type cast could help.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: COPR repo in mock?

[Dmitrij S. Kryzhevich]

Are there any instructions on how to use a COPR repo when testing
package builds with mock? My attempts at googling this sort of thing
didn't turn anything up.
Thanks,
Dave



Like any others. Provide information about repo to /etc/mock/YOURCONFIG.cfg
In most cases in would be: /etc/mock/default.cfg

You could find details for your particular copr repo in file with 
corresponding name in /etc/yum.repos.d dir if this repo already 
worldwide enabled in your system.






--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi

[Dmitrij S. Kryzhevich]

On Tue, Dec 22, 2015 at 12:34 PM, Dmitrij S. Kryzhevich
 wrote:

And now it is locked. I just can't drop it and redone (it is locked) and I
can't do anything (it is locked).
Any ideas?


Check this https://fedoraproject.org/wiki/Bodhi2#FAQ

Regards,
Parag.


Well, seems that "in some cases, a push may be failing for several days" 
IS the case.


Dmitrij
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi

[Dmitrij S. Kryzhevich]

And now it is locked. I just can't drop it and redone (it is locked) and 
I can't do anything (it is locked).

Any ideas?

Dmitrij


Hi!

Could anybody help to figure out what gone wrong here?
https://bodhi.fedoraproject.org/updates/FEDORA-2015-6ec19b0161

Dmitrij
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Bodhi

[Dmitrij S. Kryzhevich]

Hi!

Could anybody help to figure out what gone wrong here? 
https://bodhi.fedoraproject.org/updates/FEDORA-2015-6ec19b0161


Dmitrij
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: koji and opempi

[Dmitrij S. Kryzhevich]

Anyway is there a way to run scratch build for epel7 with ordinal
surrounding (openmpi-1.6.4)?

There is no way to do this


Wright answer should be: enable CR repo for CentOS.

Dmitrij
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org