Re: buildroot problems on rawhide i386, armv7hl ??
I filed https://bugzilla.redhat.com/show_bug.cgi?id=1822468 on glibc,
maybe they can direct us to the right way.
On 4/9/20 8:12 AM, Zdenek Dohnal wrote:
> I have the same issue with vim's build:
>
> https://kojipkgs.fedoraproject.org//work/tasks/8185/43148185/build.log
>
> I did the diff of installed packages between the last successful build
> and the failed one and the packages which changed are:
>
> glibc
>
> openssl-libs
>
> krb5-libs
>
> qt5-srpm-macros
>
> graphite2
>
> Since the segfault comes from functions as make/xargs - can it be
> possible the glibc update could cause it?
>
> On 4/9/20 7:29 AM, Lumir Balhar wrote:
>> On 4/9/20 6:22 AM, Jerry James wrote:
>>> On Wed, Apr 8, 2020 at 9:57 PM Sérgio Basto wrote:
I'm having the same problem
https://koji.fedoraproject.org/koji/taskinfo?taskID=43144692
>>> Me, too. Two packages, both failing on the 32-bit architectures due
>>> to segfaults in find, grep, or xargs in the alt-ergo case (it's hard
>>> to tell) and remake in the flocq case.
>>>
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=43145509
>>>
>> The same problem here. It seems to be caused by find in my case in
>> /usr/lib/rpm/brp-strip-static-archive and check-buildroot
>>
>> /usr/lib/rpm/check-buildroot: line 32: 18998 Done
>> find "$RPM_BUILD_ROOT" \! \( -name '*.pyo' -o -name '*.pyc' -o -name
>> '*.elc' -o -name '.packlist' \) -type f -print0
>> 18999 Segmentation fault (core dumped) | LANG=C xargs -0r
>> -P$NCPUS -n16 grep -F "$RPM_BUILD_ROOT" >> $tmp
>>
>> + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
>> /usr/lib/rpm/brp-strip-static-archive: line 17: 19034
>> Done find "$RPM_BUILD_ROOT" -type f \! -regex
>> "${RPM_BUILD_ROOT}/*usr/lib/debug.*" -print0
>> 19035 Segmentation fault (core dumped) | xargs -0 -r
>> -P$NCPUS -n32 sh -c "file \"\$@\" | sed 's/: */: /' | grep 'current
>> ar archive' | sed -n -e 's/^\(.*\):[ ]*current ar archive/\1/p' |
>> xargs -d '\n' -I\{\} $STRIP -g \{\}" ARG0
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=43149093
>>
>> ___
>> 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
--
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C
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: buildroot problems on rawhide i386, armv7hl ??
I have the same issue with vim's build:
https://kojipkgs.fedoraproject.org//work/tasks/8185/43148185/build.log
I did the diff of installed packages between the last successful build
and the failed one and the packages which changed are:
glibc
openssl-libs
krb5-libs
qt5-srpm-macros
graphite2
Since the segfault comes from functions as make/xargs - can it be
possible the glibc update could cause it?
On 4/9/20 7:29 AM, Lumir Balhar wrote:
> On 4/9/20 6:22 AM, Jerry James wrote:
>> On Wed, Apr 8, 2020 at 9:57 PM Sérgio Basto wrote:
>>> I'm having the same problem
>>>
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=43144692
>> Me, too. Two packages, both failing on the 32-bit architectures due
>> to segfaults in find, grep, or xargs in the alt-ergo case (it's hard
>> to tell) and remake in the flocq case.
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=43145509
>>
> The same problem here. It seems to be caused by find in my case in
> /usr/lib/rpm/brp-strip-static-archive and check-buildroot
>
> /usr/lib/rpm/check-buildroot: line 32: 18998 Done
> find "$RPM_BUILD_ROOT" \! \( -name '*.pyo' -o -name '*.pyc' -o -name
> '*.elc' -o -name '.packlist' \) -type f -print0
> 18999 Segmentation fault (core dumped) | LANG=C xargs -0r
> -P$NCPUS -n16 grep -F "$RPM_BUILD_ROOT" >> $tmp
>
> + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
> /usr/lib/rpm/brp-strip-static-archive: line 17: 19034
> Done find "$RPM_BUILD_ROOT" -type f \! -regex
> "${RPM_BUILD_ROOT}/*usr/lib/debug.*" -print0
> 19035 Segmentation fault (core dumped) | xargs -0 -r
> -P$NCPUS -n32 sh -c "file \"\$@\" | sed 's/: */: /' | grep 'current
> ar archive' | sed -n -e 's/^\(.*\):[ ]*current ar archive/\1/p' |
> xargs -d '\n' -I\{\} $STRIP -g \{\}" ARG0
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43149093
>
> ___
> 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
--
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C
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: Geany Plugins build fails due to missing webkigtk4 on aarch64/s390x - Need support
On Wed, 2020-04-08 at 21:18 +0200, Dominic Hopf via devel wrote:
> ```
> %if 0%{?rhel}
> BuildRequires: webkitgtk4-devel
> %else
> BuildRequires: webkit2gtk3-devel
> %endif
> ```
Hi,
this is an off topic for this thread, but maybe you'll find it useful.
You can use this (pick the one, which is truly needed, or both):
BuildRequires: pkgconfig(webkit2gtk-4.0)
BuildRequires: pkgconfig(webkit2gtk-web-extension-4.0)
and it'll work in all EPEL7, EPEL8 and Fedora. No need for conditionals
for the 'rhel' variable. This is how for example Evolution looks for
WebKitGTK+ development files. There was not needed any change in the
.spec file when the WebKitGTK+ package had been renamed.
Bye,
Milan
___
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: buildroot problems on rawhide i386, armv7hl ??
On 4/9/20 6:22 AM, Jerry James wrote:
On Wed, Apr 8, 2020 at 9:57 PM Sérgio Basto wrote:
I'm having the same problem
https://koji.fedoraproject.org/koji/taskinfo?taskID=43144692
Me, too. Two packages, both failing on the 32-bit architectures due
to segfaults in find, grep, or xargs in the alt-ergo case (it's hard
to tell) and remake in the flocq case.
https://koji.fedoraproject.org/koji/taskinfo?taskID=43145509
The same problem here. It seems to be caused by find in my case in
/usr/lib/rpm/brp-strip-static-archive and check-buildroot
/usr/lib/rpm/check-buildroot: line 32: 18998 Done
find "$RPM_BUILD_ROOT" \! \( -name '*.pyo' -o -name '*.pyc' -o -name
'*.elc' -o -name '.packlist' \) -type f -print0
18999 Segmentation fault (core dumped) | LANG=C xargs -0r
-P$NCPUS -n16 grep -F "$RPM_BUILD_ROOT" >> $tmp
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
/usr/lib/rpm/brp-strip-static-archive: line 17: 19034
Done find "$RPM_BUILD_ROOT" -type f \! -regex
"${RPM_BUILD_ROOT}/*usr/lib/debug.*" -print0
19035 Segmentation fault (core dumped) | xargs -0 -r -P$NCPUS
-n32 sh -c "file \"\$@\" | sed 's/: */: /' | grep 'current ar archive'
| sed -n -e 's/^\(.*\):[ ]*current ar archive/\1/p' | xargs -d '\n'
-I\{\} $STRIP -g \{\}" ARG0
https://koji.fedoraproject.org/koji/taskinfo?taskID=43149093
___
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: Modularity Survey
On Wed, Apr 8, 2020 at 7:18 PM Adam Williamson wrote: > > I personally considered it quite clear that the intended meaning was that > > they are not giving the data away to anyone external deliberately. Your > > responses will be read and understood by a very small group of people and > > not published in raw form. Yes there are servers and software providers > > along the way. But this way you could also include the ISPs who also are > > not prevented from snooping in your packets (and it's trivial at least > for > > plain text emails). And even if they provided a "direct" way to send your > > responses to their email, and we ignored the ISPs, still, Google is the > > email provider for most RedHatters. So there's no improvement at all. > > Er. It's a Google Survey, provided over https. Email is not involved. > No, it isn't. I was just trying to point out that even if they said "send us your responses directly to our email", it wouldn't be better for people's privacy, but possibly even slightly worse. It wasn't directly related to what you said but rather to "Once again, Fedora is depending on third-party, proprietary, privacy-invading SaaS" sentiment. I probably should have quoted it better. ___ 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: buildroot problems on rawhide i386, armv7hl ??
On Wed, Apr 8, 2020 at 9:57 PM Sérgio Basto wrote: > I'm having the same problem > > https://koji.fedoraproject.org/koji/taskinfo?taskID=43144692 Me, too. Two packages, both failing on the 32-bit architectures due to segfaults in find, grep, or xargs in the alt-ergo case (it's hard to tell) and remake in the flocq case. https://koji.fedoraproject.org/koji/taskinfo?taskID=43145509 -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: buildroot problems on rawhide i386, armv7hl ??
On Wed, 2020-04-08 at 19:40 -0700, Kevin Buettner wrote: > Hi, > > I'm seeing some build failures for i386 and armv7hl when attempting a > scratch build of the gdb package. These problems don't appear to be > at all related to the problem that I was fixing. In each case, a > segfault > occurs when running "make". > > The koji task is here: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=43142207 > > These lines from build.log for each of the failed architectures > are of particular interest... > > i686: > /var/tmp/rpm-tmp.sPcxFA: line 67: 3172976 Segmentation > fault (core dumped) make -j48 CFLAGS="$CFLAGS $FPROFILE_CFLAGS" > LDFLAGS="$LDFLAGS $FPROFILE_CFLAGS" V=1 maybe-configure-gdb > > armv7hl: > /var/tmp/rpm-tmp.v0nO1O: line 67: 20822 Segmentation fault (core > dumped) make -j5 CFLAGS="$CFLAGS $FPROFILE_CFLAGS" LDFLAGS="$LDFLAGS > $FPROFILE_CFLAGS" V=1 maybe-configure-gdb > > Direct links to the build.log files are as follows: > > i686: > https://kojipkgs.fedoraproject.org//work/tasks/2274/43142274/build.log > > armv7hl: > https://kojipkgs.fedoraproject.org//work/tasks/2273/43142273/build.log > > Any thoughts about why this is happening? I'm having the same problem https://koji.fedoraproject.org/koji/taskinfo?taskID=43144692 -- Sérgio M. B. ___ 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
buildroot problems on rawhide i386, armv7hl ??
Hi, I'm seeing some build failures for i386 and armv7hl when attempting a scratch build of the gdb package. These problems don't appear to be at all related to the problem that I was fixing. In each case, a segfault occurs when running "make". The koji task is here: https://koji.fedoraproject.org/koji/taskinfo?taskID=43142207 These lines from build.log for each of the failed architectures are of particular interest... i686: /var/tmp/rpm-tmp.sPcxFA: line 67: 3172976 Segmentation fault (core dumped) make -j48 CFLAGS="$CFLAGS $FPROFILE_CFLAGS" LDFLAGS="$LDFLAGS $FPROFILE_CFLAGS" V=1 maybe-configure-gdb armv7hl: /var/tmp/rpm-tmp.v0nO1O: line 67: 20822 Segmentation fault (core dumped) make -j5 CFLAGS="$CFLAGS $FPROFILE_CFLAGS" LDFLAGS="$LDFLAGS $FPROFILE_CFLAGS" V=1 maybe-configure-gdb Direct links to the build.log files are as follows: i686: https://kojipkgs.fedoraproject.org//work/tasks/2274/43142274/build.log armv7hl: https://kojipkgs.fedoraproject.org//work/tasks/2273/43142273/build.log Any thoughts about why this is happening? Kevin ___ 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
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: Geany Plugins build fails due to missing webkigtk4 on aarch64/s390x - Need support
Thanks very much for pointing that out! I'm not sure if it's really a big problem if the whole geany-plugins stuff will not be available on aarch64 and s390x, though. Unfortunately I was unable to apply that %ifnarch properly off the cuff. I guess I will have to dive even deeper into that topic in the next few days. Regards, Dominic On Wed, Apr 8, 2020 at 10:43 PM Scott Talbert wrote: > On Wed, 8 Apr 2020, Dominic Hopf via devel wrote: > > > Thanks very much for your help Scott and Michael! > > I now did both, changed the requirement to webkit2gtk3-devel and as > this one > > is also not available on the mentioned architectures, > > excluded those architectures using ExcludeArch for this specific > subpackage. > > > > The package built fine now without any errors. :-) > > > > Thanks very much and Best Regards, > > Take care of yourself within these strange times! > > I don't think that's quite what happened though. It looks like there were > no builds done at all for s390x and aarch64. It seems that ExcludeArch > applies to the whole package and not a subpackage. If you want to just > exclude a subpackage, you need to use %ifnarch, see: > https://src.fedoraproject.org/rpms/wxGTK3/blob/epel8/f/wxGTK3.spec#_46 > > Scott > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 33 System-Wide Change proposal: Perl 5.32
https://fedoraproject.org/wiki/Changes/perl5.32 == Summary == A new ''perl 5.32'' version brings a lot of changes done over a year of development. Perl 5.32 will be released in May 2020. See [https://metacpan.org/pod/release/XSAWYERX/perl-5.31.10/pod/perldelta.pod 5.31.10 perldelta] for more details about preparing release. == Owner == * Name: [[User:Jplesnik| Jitka Plesníková]] * Email: * Name: [[User:Ppisar| Petr Písař]] * Email: === Completed Items === === Items in Progress === === Items to Be Done === * Upstream to release Perl 5.32 * Get dedicated build-root * Define perl_bootstrap in perl-srpm-macros * Rebase perl to 5.32.0 * Rebuild dual-lived packages (otherwise dnf recommends --skip-broken and fails) * Rebuild packages needed for minimal build-root * Rebuild packages needed for building source packages from git repository * Rebuild other packages: Use Fedora::Rebuild dependency solver * Undefine perl_bootstrap * Rebuild packages having perl_bootstrap condition in spec file * Rebuild all updated packages * [https://jplesnik.fedorapeople.org/5.32/ Final lists of results] * Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs * Synchronize packages upgraded in ''f33'' build root * Rebuilt Perl packages: 0 of 3182 done (0.00%) * Failed builds (0): == Detailed Description == New perl is released every year and updates containing mainly bug fixes follow during the year. The 5.32.0 version is stable release this year. == Benefit to Fedora == Up-to-date and latest perl release will be delivered to Fedora users. == Scope == Every Perl package will be rebuilt in a dedicated ''f33-perl'' build-root against perl 5.32.0 and then if no major problem emerges the packages will be merged back to ''f33'' build-root. * Proposal owners: New perl and all packages requiring perl or a Perl module will be rebuilt into ''f33-perl'' build-root. * Other developers: Owners of packages that fail to rebuild, mainly perl-sig users, will be asked using Bugzilla to fix or remove their packages from the distribution. * Release engineering: [https://pagure.io/releng/issue/9387 #9387] Release engineers will be asked for new ''f33-perl'' build-root inheriting from ''f33'' build-root. After successful finishing the rebuild, they will be asked to merge ''f33-perl'' packages back to ''f33'' build-root. * Policies and guidelines: No policies have to be modified to complete this change. == Upgrade/compatibility impact == Vast majority of functionality will be preserved. Only the packages that failed to build against perl 5.30 will be removed from the distribution. That will require to remove those packages from existing systems otherwise package manager will encounter unsatisfied dependencies. == How To Test == Try upgrading from Fedora 32 to 33. Try some Perl application to verify they work as expected. Try embedded perl in slapd or snmpd. == User Experience == There should not be any remarkable change in user experience. With the exception that previously locally installed modules with a CPAN clients will need a reinstalation. == Dependencies == There is more than 3100 packages depending on perl. Most of them are expected not to break. Finishing this change can be endangered only by critical changes in a toolchain. == Contingency Plan == If we find perl 5.32 is not suitable for Fedora 33, we will revert back to perl 5.30 and we drop the temporary build-root with already rebuilt packages. * Contingency deadline: branching Fedora 33 from Rawhide. * Blocks release? No. == Documentation == * perldelta * An announcement on the perl-devel mailing list * An announcement on fedora-devel mailing list == Release Notes == * TBD - when release candidate appears -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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: Geany Plugins build fails due to missing webkigtk4 on aarch64/s390x - Need support
On Wed, 8 Apr 2020, Dominic Hopf via devel wrote: Thanks very much for your help Scott and Michael! I now did both, changed the requirement to webkit2gtk3-devel and as this one is also not available on the mentioned architectures, excluded those architectures using ExcludeArch for this specific subpackage. The package built fine now without any errors. :-) Thanks very much and Best Regards, Take care of yourself within these strange times! I don't think that's quite what happened though. It looks like there were no builds done at all for s390x and aarch64. It seems that ExcludeArch applies to the whole package and not a subpackage. If you want to just exclude a subpackage, you need to use %ifnarch, see: https://src.fedoraproject.org/rpms/wxGTK3/blob/epel8/f/wxGTK3.spec#_46 Scott ___ 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: Geany Plugins build fails due to missing webkigtk4 on aarch64/s390x - Need support
Thanks very much for your help Scott and Michael!
I now did both, changed the requirement to webkit2gtk3-devel and as
this one is also not available on the mentioned architectures,
excluded those architectures using ExcludeArch for this specific subpackage.
The package built fine now without any errors. :-)
Thanks very much and Best Regards,
Take care of yourself within these strange times!
Dominic
On Wed, Apr 8, 2020 at 10:04 PM Michael Catanzaro
wrote:
> On Wed, Apr 8, 2020 at 9:18 pm, Dominic Hopf via devel
> wrote:
> > ```
> > %if 0%{?rhel}
> > BuildRequires: webkitgtk4-devel
> > %else
> > BuildRequires: webkit2gtk3-devel
> > %endif
> > ```
>
> FYI: this package was renamed for RHEL 8. webkitgtk4 is the RHEL 7
> package. webkit2gtk3 is the equivalent RHEL 8 package. Exact same
> thing, less-confusing name.
>
> So there is no webkitgtk4 in RHEL 8. If webkitgtk4-devel is present in
> the buildroot allowing the build to succeed on any architecture, I
> guess something is wrong with the buildroot.
>
>
>
___
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
Schedule for Thursday's FPC Meeting (2020-04-09 16:00 UTC)
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-04-09 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
= Day: Thursday ==
2020-04-09 09:00 PDT US/Pacific
2020-04-09 12:00 EDT --> US/Eastern <--
2020-04-09 16:00 UTC UTC
2020-04-09 17:00 BST Europe/London
2020-04-09 18:00 CEST Europe/Berlin
2020-04-09 18:00 CEST Europe/Paris
2020-04-09 21:30 IST Asia/Calcutta
New Day: Friday -
2020-04-10 00:00 HKT Asia/Hong_Kong
2020-04-10 00:00 +08 Asia/Singapore
2020-04-10 01:00 JST Asia/Tokyo
2020-04-10 02:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
= Followup Issues =
#topic #907 Which %__foo macros for executables are acceptable?
.fpc 907
https://pagure.io/packaging-committee/issue/907
#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909
= New Issues =
#topic #958 Update of the Haskell Packaging Guidelines
.fpc 958
https://pagure.io/packaging-committee/issue/958
#topic #959 Is it ok to have different version based on %{fedora}?
.fpc 959
https://pagure.io/packaging-committee/issue/959
#topic #963 Blanket Bootstrap Exception for building Mono
.fpc 963
https://pagure.io/packaging-committee/issue/963
= Followup Pull Requests =
#topic #pr-814 Add SELinux Independent Policy Guidelines
https://pagure.io/packaging-committee/pull-request/814
#topic #pr-938 Add Package Review Process page
https://pagure.io/packaging-committee/pull-request/938
= New Pull Requests =
#topic #pr-#942 Recommend storing changelog entries in separate file.
https://pagure.io/packaging-committee/pull-request/942
#topic #pr-#947 Deprecate Old Style Dependency Generators
https://pagure.io/packaging-committee/pull-request/947
#topic #pr-#951 Fonts: document “I need (any) font file to be present”
https://pagure.io/packaging-committee/pull-request/951
#topic #pr-#954 Prohibit use of `rpm` command from specfile.
https://pagure.io/packaging-committee/pull-request/954
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
If you would like to add something to this agenda, you can:
* Reply to this e-mail
* File a new ticket at: https://pagure.io/packaging-committee
* E-mail me directly
* Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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: Geany Plugins build fails due to missing webkigtk4 on aarch64/s390x - Need support
On Wed, Apr 8, 2020 at 9:18 pm, Dominic Hopf via devel
wrote:
```
%if 0%{?rhel}
BuildRequires: webkitgtk4-devel
%else
BuildRequires: webkit2gtk3-devel
%endif
```
FYI: this package was renamed for RHEL 8. webkitgtk4 is the RHEL 7
package. webkit2gtk3 is the equivalent RHEL 8 package. Exact same
thing, less-confusing name.
So there is no webkitgtk4 in RHEL 8. If webkitgtk4-devel is present in
the buildroot allowing the build to succeed on any architecture, I
guess something is wrong with the buildroot.
___
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: F32 ELF file analysis
What are you using to check for your STACK_PROT This is annocheck Alternate: - $ readelf --segments ./the_app Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz Flags Align GNU_STACK 0x 0x 0x 0x 0x RW 0x10 - where this app uses only "RW" and not "X", so the stack is not executable. ___ 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: Geany Plugins build fails due to missing webkigtk4 on aarch64/s390x - Need support
On Wed, 8 Apr 2020, Dominic Hopf via devel wrote:
Greetings,
I'm trying to build Geany and the Geany Plugins for EPEL8 currently and
stumble over an issue which seems to be
quite special in some kind for aarch64 and s390x:
https://koji.fedoraproject.org/koji/taskinfo?taskID=43133907
Basically I merged the epel7 branch into the epel8 branch for that build,
the geany-plugins-markdown plugin required webkitgtk4-devel so far:
```
%if 0%{?rhel}
BuildRequires: webkitgtk4-devel
%else
BuildRequires: webkit2gtk3-devel
%endif
```
I'm a bit confused and unsure how to proceed further as the build obviously
worked fine for ppc64le and x86_64.
You should probably be using webkit2gtk3-devel on EPEL8 as its newer and
more up to date.
Unfortunately, there is a bit of discrepancy in RHEL8 related to
development packages not being provided on various architectures. You
will probably have to use ExcludeArch for s390x and aarch64 (for now).
See:
https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.3F
Scott___
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
Geany Plugins build fails due to missing webkigtk4 on aarch64/s390x - Need support
Greetings,
I'm trying to build Geany and the Geany Plugins for EPEL8 currently and
stumble over an issue which seems to be
quite special in some kind for aarch64 and s390x:
https://koji.fedoraproject.org/koji/taskinfo?taskID=43133907
Basically I merged the epel7 branch into the epel8 branch for that build,
the geany-plugins-markdown plugin required webkitgtk4-devel so far:
```
%if 0%{?rhel}
BuildRequires: webkitgtk4-devel
%else
BuildRequires: webkit2gtk3-devel
%endif
```
I'm a bit confused and unsure how to proceed further as the build obviously
worked fine for ppc64le and x86_64.
Thanks very much for any advise how to solve this issue.
Regards,
Dominic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, 6 Apr 2020, 21:26 clime, wrote: > On Mon, 6 Apr 2020 at 17:52, Leigh Griffin wrote: > > > > > > > > On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson < > adamw...@fedoraproject.org> wrote: > >> > >> On Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote: > >> > > >> > > Does it mean you didn't consider dist-git<->zuul integration vs. > Gitlab > >> > > CI? I.e. technical differences and advantages of each? If you did, > can you, > >> > > please, publish it? It would be valuable info for the community and > >> > > something we can comment on. > >> > > > >> > > >> > Gitlab CI was not part of our evaluation, we are aware it's a service > that > >> > is offered but did not evaluate it as it wasn't within the scope of > our > >> > exercise. > >> > >> So, how does that track with this quote from the decision blog post? > >> > >> "Some top level requirements which helped us arrive at this decision > >> [to choose Gitlab]: > >> > >> There is a need for CentOS Stream to integrate with a kernel workflow > >> that is an automated bot driven merging solution (merge trains). This > >> allows for richer CI capabilities and minimises the need for human > >> interaction" > >> > >> If you did not evaluate Gitlab CI (and presumably CI capabilities of > >> the three systems more widely), how did the need for a CI feature - > >> that is what "merge trains" are - act as a "top level requirement" > >> which "helped us arrive at this decision"? > > > > > > I'm talking specifically about CI as a capability, in that specific > integrations at a CI level for hooks and other nice stuff which has several > known issues in Pagure at an API level, we evaluated that high level > requirement. Some stakeholders do not want to use the built in Gitlab CI as > we have CentOS CI used extensively and some have homebrewed systems that > they use. Hence why we did not go deep on CI at a very functional level > outside of known limitations and desires that came up as direct > requirements. > > > > Merge trains and that capability is plugin / CI based and was explicit > in it's scope (it was called out as a need to have merge train > functionality) Vs CI in general as it was named as a need. We had discussed > that Zuul was a possibility around Pagure as part of that. > > Discussed with whom, do you have logs? You didn't provide any material > from which the conclusions could be reproducibly drawn, you just came > and told us: "Hey, we decided this and this, you don't have any other > choice than to comply". It doesn't work like that or at least it > shouldn't, in my opinion. > > It doesn't seem that you have considered CI future for Fedora _at > all_, i.e. work needed for pagure-based solution vs. work needed for > gitlab-based solution. Sorry but if you don't have a clear and > presentable vision of the different setups and how they compare to > each other with respect to initial setup, maintenance cost, and > feature set relevant for packager workflows, you shouldn't be making > decisions like those. Your "let's go to Gitlab" is shooting in the > dark at best. > Let me add here: we had conversation on CI with CPE both as Fedora CI SIG and as RHEL CI team. We do want to keep existing CI infrastructure based on message exchange with distributed CI systems. As Gitlab has API and messages in a certain form, I don't expect huge problems here. And we mentioned Zuul in that conversation. We discussed the possibility for Zuul to work with Gitlab at Devconf in January. And my understanding alignes with what Fabien said in this thread, that Zuul _can_ work with Gitlab. Though it might require some adjustments. Personally, I believe that Zuul is superior to any other CI system when it comes to managing pull-requests workflow, and I would like to see its usage increased in Fedora and beyond. But I think changing the Git Forge to Gitlab doesn't on its own create a problem for this view. What I would consider a problem: if we take Gitlab as GitForge, but then users start to request more "nice features", more "easy integrations" and more Gitlab-specific workflows... The git forge itself is not as harmful, as the scope creep in can bring. But this is not something the CPE team should manage alone, it is us as users who need to be disciplined in the usage of this tool and our requests to it. > clime > > > > > > >> > >> -- > >> Adam Williamson > >> Fedora QA Community Monkey > >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > >> http://www.happyassassin.net > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > > > > > -- >
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On 4/8/20 3:42 AM, Miroslav Lichvar wrote: On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote: It doesn't make much sense to me for this to default to on if we still "trust" the DNS servers provided over DHCP. What is the issue with using untrusted DNS servers here? An NTS client is supposed to verify the certificates. Local MITM attackers shouldn't be able to force the client to synchronize to a different NTP server. (Of course, they can always disable the synchronization.) I'm not saying there is necessarily an issue, just a logical inconsistency. If the DNS servers provided by DHCP are trusted, why would any plain NTP servers also provided by DHCP not be trusted? I can do nefarious things with either. Generally speaking, on a network I admin, if I've configured DHCP to provide things like NTP and DNS servers, it's because I intend client devices to use those things. While some devices choose to ignore DHCP provided DNS (and NTP), I can still reroute those requests at the edge router. Is that also possible with NTS? Even if it gets rerouted to a plain NTP server? Additionally, it's not clear to me from the proposal what it would take for an NTP server provided over DHCP to be "trusted", or what a "trusted network" is. Are only NTS-enabled sources to be trusted? Generally, yes. What I meant, if someone for example had at home a stratum 1 server (e.g. synchronized to GPS) and they trusted everything and everyone in their local network, it would make sense to still use the server (without NTS) in addition to any external time servers authenticated by NTS. The question is if we need to change the default value of the PEERNTP option. There could be a new default which adds the servers provided by DHCP only if chronyd is not using any servers with enabled authentication. That makes sense. But again, if I don't trust everything and everyone in my network, why do I trust the provided DNS servers? I feel like if this is on by default we're basically saying nobody trusts any provided NTP server unless it supports NTS. If that's the case, do away with the 'trusted network' verbiage and just say that only NTS servers provided over DHCP will be used. Additionally, what about the no-internet case? Will a local, non-NTS NTP server be acceptable in that case? I feel like that would be handled by the change to PEERNTP you mention above. But then can't attackers "disable the synchronization" as you mention above, essentially forcing us back to no additional security? Maybe what we should really have is a REQUIRENTS option for chronyd? What becomes of the old default fedora.pool.ntp.org? It would still work, even if we didn't use it by default. The name is just an alias for pool.ntp.org. The servers used in the current default configuration are not run by Fedora. Does the alias provide no additional functionality? Does it help with an estimate of running Fedora machines in the wild? Finally, from a purely personal standpoint, I don't like seeing yet more infrastructure being handed over to a hyperscaler like Cloudflare (see also DoH in Firefox). I would be less opposed to this being default if pool.ntp.org found a way to support it. Yes, that's a valid point, which we need to consider. I don't have a strong opinion either way. I'd like to see pool.ntp.org to support NTS. But I'm not sure if the trust of not being attacked will be comparable to a single entity running the servers, even if the pool has a sufficient number of NTS-enabled servers and implements some mitigations like mixing servers from different countries. Will there be some kind of 'canary domain' like there is for DoH (use-application-dns.net)? Again from a network admin standpoint, if I provide a local NTP server without NTS, I want an easy way to tell the devices I manage to use it. From a user standpoint, I like this change and the security it offers. But with a network admin hat on, it feels like yet more local infrastructure being pushed outside of my control. ___ 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: Modularity Survey
Updated. Thanks both of you for the suggestion. Dne 08. 04. 20 v 19:59 Adam Williamson napsal(a): On Wed, 2020-04-08 at 13:47 -0400, Alex Scheel wrote: Hey Daniel, do you mind updating the GDPR compliance tag to include Google? Right, this is all I intended in the first place :) A simple: -The raw data will not be provided to anyone else at Red Hat or any 3rd parties +The raw data will not be provided to anyone else at Red Hat or any 3rd parties (except Google) would do the trick just fine. We didn't need a big thread about it... ___ 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: Modularity Survey
On Wed, 2020-04-08 at 13:47 -0400, Alex Scheel wrote: > Hey Daniel, do you mind updating the GDPR compliance tag to include > Google? Right, this is all I intended in the first place :) A simple: -The raw data will not be provided to anyone else at Red Hat or any 3rd parties +The raw data will not be provided to anyone else at Red Hat or any 3rd parties (except Google) would do the trick just fine. We didn't need a big thread about it... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity Survey
Hey Daniel, do you mind updating the GDPR compliance tag to include Google? Thanks! - Original Message - > From: "Adam Williamson" > To: "Development discussions related to Fedora" > > Sent: Wednesday, April 8, 2020 1:22:27 PM > Subject: Re: Modularity Survey > > On Wed, 2020-04-08 at 08:41 -0400, Alex Scheel wrote: > > > > There's a marketing piece from 2017 that alleges that none of gsuite > > (including their gmail for gsuite!) gets scanned for ads: > > > > https://www.blog.google/products/gmail/g-suite-gains-traction-in-the-enterprise-g-suites-gmail-and-consumer-gmail-to-more-closely-align/ > > > > > > I think we can agree that--at one point in time (2014-2017)--Google's > > position was that they aren't scanning gsuite content. > > But that's not what a GDPR declaration is about at all. It doesn't have > anything to do with what the entity who gets the data claims they are > or are not doing with it. Only with whether or not they get the data. > > I don't know or care whether Google is automatically scanning the > content for the purpose of showing advertising or not, really. But > that's not the question here at all. I'm going to quit responding sometime as this really has gotten out of hand, but please look at the context for my original mail in this subthread. Please, read the context in which I was responding! https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RGNGPXMXW4E6W4X6DUTLYWI4ZYQS3CHF/ and https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BBA25DUX4HZMYLGEDS7ZDLN2SQX5IYFU/ > > Indeed. Once again, Fedora is depending on third-party, proprietary, > > privacy-invading SaaS. > Meets exactly my thoughts... > This is yet again another disappointing choice of tool. > > I'm not going to give anything to Google, hence I can _not_ answer the > survey. > Too bad, there is much to be said about modularity, as the lengthy > threads have already shown. > > Unfortunately, Fedora is drifting more and more away from the Libre > Software philosophy that over time made me a Linux-only user and a > Fedora packager. At some point, I will have to put my money where my > mouth is and find another ship. > Yes, I'm bitter... The replies I was responding to weren't expressly GDPR comments! They're attacks on people! IMO, that should've been called out. So I did. I agree, from a GDPR compliance perspective, someone with access to the survey could add a disclaimer. But insinuations that Google is using the data submitted by this form, on their own, is IMO, wrong. And should be called out. That's why I did. > > I'll make the assumption that, were this to have changed, a number > > of large businesses would've been upset and there would've been > > media reports and potentially legal proceedings. I haven't found > > any. :-) > > Again I don't know why you're all making assumptions like this? Don't > you read the news? Google (and Facebook et al) have been "caught" doing > all sorts of stuff with user data all the time. It does make the news. > Frequently. I do read the news. Google and Facebook have been caught abusing **individual** data. I agree with you on that. I think it is wrong and they should stop. But we're not talking about that. We're talking about an enterprise gsuite account with a contract between Google and Red Hat. Where are the news articles about Google doing data mining on other companies data? Perhaps I've missed all the relevant news articles though. I'd imagine, with all the data companies store in Google drive, this would've been an easy case. To not use GMail is one thing. To attack those who created an optional survey--based on an unproven premise--is IMO, out of line. It isn't being excellent to others. And to be clear, the two posters I replied to weren't being excellent; you were ok. - Alex ___ 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: Modularity Survey
On Wed, 2020-04-08 at 08:41 -0400, Alex Scheel wrote: > > There's a marketing piece from 2017 that alleges that none of gsuite > (including their gmail for gsuite!) gets scanned for ads: > > https://www.blog.google/products/gmail/g-suite-gains-traction-in-the-enterprise-g-suites-gmail-and-consumer-gmail-to-more-closely-align/ > > > I think we can agree that--at one point in time (2014-2017)--Google's > position was that they aren't scanning gsuite content. But that's not what a GDPR declaration is about at all. It doesn't have anything to do with what the entity who gets the data claims they are or are not doing with it. Only with whether or not they get the data. I don't know or care whether Google is automatically scanning the content for the purpose of showing advertising or not, really. But that's not the question here at all. > I'll make the assumption that, were this to have changed, a number > of large businesses would've been upset and there would've been > media reports and potentially legal proceedings. I haven't found > any. :-) Again I don't know why you're all making assumptions like this? Don't you read the news? Google (and Facebook et al) have been "caught" doing all sorts of stuff with user data all the time. It does make the news. Frequently. https://www.theverge.com/interface is a good column if you want to keep up with this sort of stuff. But, regardless, it *doesn't matter*. If you're going to make a declaration about who's getting the data, it should be accurate. It doesn't matter what those entities are or are not doing with it, because that's not what your declaration said, it didn't say "this data is only being given to third parties who pinky-swear not to automatically scan it for advertising purposes", it said "The raw data will not be provided to anyone else at Red Hat or any 3rd parties". -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity Survey
On Wed, 2020-04-08 at 10:25 +0200, Kamil Paral wrote: > On Tue, Apr 7, 2020 at 7:22 PM Adam Williamson > wrote: > > > On Tue, 2020-04-07 at 13:12 -0400, Alex Scheel wrote: > > > I'm sure we can trust that Red Hat did its > > > > > > due diligence and Google isn't using responses to a customer's form to > > > > > > track those taking the survey. > > > > I don't really know why you'd think anyone can trust that. Google > > tracks everyone everywhere as hard as it can. It's what Google *does*. > > > > But I didn't actually suggest it's Terribly Awful to run this survey > > through Google. I just said the privacy declaration seems to be wrong. > > > > I personally considered it quite clear that the intended meaning was that > they are not giving the data away to anyone external deliberately. Your > responses will be read and understood by a very small group of people and > not published in raw form. Yes there are servers and software providers > along the way. But this way you could also include the ISPs who also are > not prevented from snooping in your packets (and it's trivial at least for > plain text emails). And even if they provided a "direct" way to send your > responses to their email, and we ignored the ISPs, still, Google is the > email provider for most RedHatters. So there's no improvement at all. Er. It's a Google Survey, provided over https. Email is not involved. "On behalf of Red Hat's Modularity team, I'd like to ask you to fill out a survey on Modularity: https://docs.google.com/forms/d/e/1FAIpQLScOA97rGONieSOYmlZLsHdkq-EhdePZ4IN3RwOjJKd1F1a9sw/viewform?usp=sf_link"; so there is no involvement of email servers, and the data is encrypted so no, your ISP can't snoop on it. I sort of got the intended meaning as well. But this seems to be a legally-required GDPR text, I don't think "we sort of get what you mean" cuts the mustard for those. If the data is going to Google it's going to Google and I think that's supposed to be declared. > I'm not saying we shouldn't talk about it, but the points mentioned are > common for most data submissions anywhere. I don't think it was the core of > the message. The bullet point I quoted was under "Privacy / GDPR:". Pretty sure it's the "core" of that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
For what it's worth, Jeremy, Randy, and others: I absolutely value your contributions both now and in the past. Members of the the Fedora Engineering team and CPE in all previous and current names and incarnations have done and continue to do amazing things which have beeen *essentially* valuable to the Fedora Project and community. -- Matthew Miller Fedora Project Leader Not the Pope ___ 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: F32 ELF file analysis
On Wednesday, April 8, 2020 11:11:36 AM EDT David Cantrell wrote: > >Just wanted to share with everyone the results of a data collection on > >various metrics of ELF files when installing just @Core group. > > > >http://people.redhat.com/sgrubb/analysis/f32-analysis.slides.html#/ > > > >I recommend clicking on the "pop out" link and then you have more room to > >see the results. To use it grab SOURCERPM and dragh it just below > >"count", then drag FILE under SOURCERPM, then grab STACK_PROT and drag it > >to the right of count. Next click on the drop down and uncheck "ok". > >Click apply. Now you have the listing of all files without the right > >stack protector hardening. > > > >Go back into the STACK_PROT, check ok, click apply. Drag STACK_PROT back > >to where it came from, grab USES_SECCOMP, drag it to the right of > >"count", click drop down, uncheck "no", click apply, now you have the > >list of programs using seccomp for confinement. > > > >Have fun playing with the data. Just remember when you subset the data, it > >stays that way until you check all boxes. In case your curious, this is > >exported from a Jupyter Notebook. > > This is a nice visual. I'm hoping it inspires people to do some poking around to help harden the OS a little more. For example, you can click on CLASS and uncheck everything but daemons. Then go down to CHANGES_UID and make only the no checked. This is how many daemons are not changing to another account and still using root. > I'd like to ensure the check in rpminspect is doing > the same thing. What are you using to check for your STACK_PROT This is annocheck > and USES_SECCOMP? readelf -s $f 2>/dev/null | grep FUNC | egrep 'seccomp_rule_add|seccomp' This detects either direct use of seccomp or use of libseccomp. Best Regards, -Steve ___ 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: unretiring CubicSDR from rawhide
Thanks Matt! KD0SMQ Geoff Marr IRC: coremodule On Wed, Apr 8, 2020 at 8:57 AM Matt Domsch wrote: > CubicSDR provides a panadapter experience, showing the RF spectrum for the > band you have selected. I use it with my Yaesu FTDX3000D radio frequently, > along with an inexpensive RTL-SDR adapter. > > I've prepared CubicSDR to be unretired from Fedora rawhide (F33), now that > wxGTK 3.1 is available in rawhide. Package review ticket here: > https://bugzilla.redhat.com/show_bug.cgi?id=1821987 > > Reviews appreciated. > > Thanks, > Matt N5MLD > > ___ > 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
Fedora 32 compose report: 20200408.n.0 changes
OLD: Fedora-32-20200407.n.0 NEW: Fedora-32-20200408.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 8 Dropped packages:0 Upgraded packages: 45 Downgraded packages: 0 Size of added packages: 24.49 MiB Size of dropped packages:0 B Size of upgraded packages: 973.39 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -18.05 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: LXQt live x86_64 Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-32-20200408.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: assetfinder-0.1.0-1.fc32 Summary: Find domains and subdomains related to a given domain RPMs:assetfinder golang-github-tomnomnom-assetfinder-devel Size:9.75 MiB Package: kemie-bellota-fonts-4.1-1.fc32 Summary: An ornamented, cute, low contrast sans-serif font family RPMs:kemie-bellota-fonts kemie-bellota-fonts-all kemie-bellota-text-fonts Size:679.15 KiB Package: libphonenumber-8.12.0-1.fc32 Summary: Library to handle international phone numbers RPMs:libphonenumber libphonenumber-devel Size:11.74 MiB Package: perl-Gnome2-Vte-0.11-15.fc32 Summary: Perl interface to the Gtk2 Virtual Terminal Emulation library RPMs:perl-Gnome2-Vte Size:296.51 KiB Package: python-asteval-0.9.18-1.fc32 Summary: Evaluator of Python expression using ast module RPMs:python-asteval-doc python3-asteval Size:195.98 KiB Package: python-flask-restx-0.2.0-1.fc32 Summary: Framework for fast, easy and documented API development with Flask RPMs:python3-flask-restx Size:1.59 MiB Package: python-fs-2.4.11-2.fc32 Summary: Python's Filesystem abstraction layer RPMs:python3-fs Size:202.31 KiB Package: python-winacl-0.0.2-1.fc32 Summary: Python ACL/ACE/Security Descriptor manipulation library RPMs:python3-winacl Size:75.20 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: alsa-lib-1.2.2-2.fc32 Old package: alsa-lib-1.2.2-1.fc32 Summary: The Advanced Linux Sound Architecture (ALSA) library RPMs: alsa-lib alsa-lib-devel alsa-topology alsa-ucm Size: 7.37 MiB Size change: 2.46 KiB Changelog: * Mon Apr 06 2020 Jaroslav Kysela - 1.2.2-2 - UCM2 fixes (RemoveDevice), bug#1786723 Package: beaker-27.4-1.fc32 Old package: beaker-27.3-1.fc32 Summary: Full-stack software and hardware integration testing system RPMs: beaker-client beaker-common Size: 242.04 KiB Size change: 1.28 KiB Changelog: * Mon Mar 30 2020 Martin Styk - 27.4-1: - Update to 27.4 (#1818717) Package: bijiben-3.36.1-1.fc32 Old package: bijiben-3.36.0-1.fc32 Summary: Simple Note Viewer RPMs: bijiben Size: 2.10 MiB Size change: 1.26 KiB Changelog: * Sun Apr 05 2020 Kalev Lember - 3.36.1-1 - Update to 3.36.1 Package: calibre-4.13.0-1.fc32 Old package: calibre-4.12.0-1.fc32 Summary: E-book converter and library manager RPMs: calibre Size: 68.38 MiB Size change: -41.74 KiB Changelog: * Sun Mar 15 2020 Marcus A. Romer - 4.12.0-2 - Use official instead of custom tarball. * Sun Apr 05 2020 Kevin Fenzi - 4.13.0-1 - Update to 4.13.0. Fixes bug #1817929 Package: chromium-80.0.3987.163-1.fc32 Old package: chromium-80.0.3987.162-1.fc32 Summary: A WebKit (Blink) powered web browser RPMs: chrome-remote-desktop chromedriver chromium chromium-common chromium-headless chromium-libs chromium-libs-media Size: 361.91 MiB Size change: 96.05 KiB Changelog: * Sat Apr 04 2020 Tom Callaway - 80.0.3987.163-1 - update to 80.0.3987.163 Package: ddnet-13.0-1.fc32 Old package: ddnet-12.9.2-1.fc32 Summary: DDraceNetwork, a cooperative racing mod of Teeworlds RPMs: ddnet ddnet-data ddnet-server Size: 18.52 MiB Size change: 36.15 KiB Changelog: * Tue Apr 07 2020 ElXreno - 13.0-1 - Updated to version 13.0 Package: elpa-2019.05.002-3.fc32 Old package: elpa-2019.05.002-1.fc32 Summary: High-performance library for parallel solution of eigenvalue problems RPMs: elpa elpa-common elpa-common-devel elpa-devel elpa-mpich elpa-mpich-devel elpa-openmpi elpa-openmpi-devel Size: 10.17 MiB Size change: -28.72 KiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 2019.05.002-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sun Apr 05 2020 Dominik Mierzejewski 2019.05.002-3 - fix test failures on x86_64 - work around compilation errors with gfortran 10 Package: fedora-obsolete-packages-32-44 Old package: fedora-obsolete-packages-32-43 Summary: A package to obsolete retired packages RPMs: fedora-obsolete-packages Size: 204.22 KiB Size change: 412 B Changelog: * Mon Apr 06 2020 Miro Hron??ok - 32-44 - Update playonlinux version - Update python2-qpid-proton version - Add back SELinux related Pyt
Re: F32 ELF file analysis
On Mon, Apr 06, 2020 at 12:03:46PM -0400, Steve Grubb wrote: Just wanted to share with everyone the results of a data collection on various metrics of ELF files when installing just @Core group. http://people.redhat.com/sgrubb/analysis/f32-analysis.slides.html#/ I recommend clicking on the "pop out" link and then you have more room to see the results. To use it grab SOURCERPM and dragh it just below "count", then drag FILE under SOURCERPM, then grab STACK_PROT and drag it to the right of count. Next click on the drop down and uncheck "ok". Click apply. Now you have the listing of all files without the right stack protector hardening. Go back into the STACK_PROT, check ok, click apply. Drag STACK_PROT back to where it came from, grab USES_SECCOMP, drag it to the right of "count", click drop down, uncheck "no", click apply, now you have the list of programs using seccomp for confinement. Have fun playing with the data. Just remember when you subset the data, it stays that way until you check all boxes. In case your curious, this is exported from a Jupyter Notebook. This is a nice visual. I'd like to ensure the check in rpminspect is doing the same thing. What are you using to check for your STACK_PROT and USES_SECCOMP? Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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: OpenSSL 3.0
On Wed, 2020-04-08 at 10:38 +0200, Miro Hrončok wrote: > On 07. 04. 20 23:31, Ben Cotton wrote: > > * Proposal owners: Provide a compat-openssl11 package, identify > > dependent packages, provide the rebased openssl package, work with > > dependent package owners on rebuilds. > > Thanks for doing this. > > Will compat-openssl11-devel be provided? For how long you intent to > support it? I originally thought that we might be able to do without the -devel subpackage as there are the usual problems with it - such as it being conflicting with the primary openssl-devel package and also potential for unstability in applications that have loaded both old and new OpenSSL into a single process. > E.g. I don't see Python 2 ever supporting openssl 3, that's why I'm > asking. The question is what does this really mean - in theory at least the API should be fully backwards compatible so what builds against openssl 1.1.1 should build against openssl 3. Of course testcases that expect bug-for-bug compatibility might not work as expected. But yeah I am not against providing compat-openssl11-devel for a few releases at least. And I can orphan the package later if someone else wants to maintain it further then. > (Replied this sooner, but accidentally to devel-announce.) > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ 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
unretiring CubicSDR from rawhide
CubicSDR provides a panadapter experience, showing the RF spectrum for the band you have selected. I use it with my Yaesu FTDX3000D radio frequently, along with an inexpensive RTL-SDR adapter. I've prepared CubicSDR to be unretired from Fedora rawhide (F33), now that wxGTK 3.1 is available in rawhide. Package review ticket here: https://bugzilla.redhat.com/show_bug.cgi?id=1821987 Reviews appreciated. Thanks, Matt N5MLD ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-31-20200408.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Passed openQA tests: 8/8 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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: Detecting when building under mock?
On Wed, 8 Apr 2020, Petr Pisar wrote: Is there a recommended way for detecting when a package is being built under mock? I have a package where some tests fail due to various things not being present in a mock container, e.g, /dev/log doesn't exist. I can just disable these tests downstream, but upstream might take a change if I can wrap them in a "if !mock" condition. Why not test for the presence of /dev/log before running such tests? Well, in the particular case of that test, checking whether /dev/log exists *is* the test. Then it's a bug in the test. Since when /dev/log must exist on a system? You can have various environments that are missing the socket. Mock is jist one of them. It's a test for a piece of code that identifies a file as a socket. So basically upstream is using /dev/log as a well-known place to find a socket file. I suppose they could/should just be creating their own. Anyway, to answer my own question, I found that the environment variable 'container' is set in mock, so that seems to be a possible way to identify a mock or container environment. Scott ___ 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: ELN Buildroot and Compose V4
On 4/7/20 1:27 PM, Stephen Gallagher wrote:
The other piece of it is that there's a UX/psychological piece to it.
If we call it .eln9.1.0, people are quite likely to skim over the 'n'
and confuse themselves into thinking it's a RHEL 9.1.0 package. That
way lies a support nightmare. We absolutely agree with your assessment
that the dist tag needs to be versioned (see my earlier mail), but we
want to disambiguate it so it doesn't look like a real RHEL package.
(I'm debating starting with a higher number like 100 so it doesn't get
confused with Fedora or RHEL versions that we're likely to see any day
soon.)
Have you considered using $YEAR or a combo of date units? Then $YEAR could be
automatically inserted if $DIST == ELN.
Version: 1.0
Release: 1%{?dist}
Output: foobar-1.0-1.eln2020
___
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: Updated review trackers pages
Il 07/04/20 16:52, Mattia Verga ha scritto: > Il 07/04/20 16:01, Ankur Sinha ha scritto: >> The list says that there aren't any trivial tickets, but easyfix does >> show one (only one): >> https://fedoraproject.org/PackageReviewStatus/trivial.html >> vs >> https://fedoraproject.org/easyfix/ >> >> Could you check this please? >> > Yeah, that's because it's listed in the "in progress" page... that > ticket has the review flag set and the assignee field is populated, but > it's state is NEW. > > I will add a page to list all tickets in inconsistent state like that one. > > Thanks > Ok, I've just pushed an "update" which moves all tickets with inconsistent state in a separate page. For "consistent" state I mean two cases: - state "NEW" + assignee not set (nob...@fedoraproject.org) + review-flag not set - state != "NEW" + assignee set + review flag set (either ? | - | +) If you are a reviewer, please check if you have any ticket assigned. I've also added a "reviewers.html" page where you can easily find what tickets are "assigned" to you (I use double quote here because this only checks if your email is set in the "assigned_to" field - there are many tickets in inconsistent state because their state is new but have an assignee set). Mattia ___ 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: ELN Buildroot and Compose V4
On 08. 04. 20 14:52, Nicolas Mailhot via devel wrote: Then use .el.9.dev. That should still order mostly fine .el9~dev would sort even better. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
Le mardi 07 avril 2020 à 14:27 -0400, Stephen Gallagher a écrit : > > The other piece of it is that there's a UX/psychological piece to it. > If we call it .eln9.1.0, people are quite likely to skim over the 'n' > and confuse themselves into thinking it's a RHEL 9.1.0 package. Then use .el.9.dev. That should still order mostly fine, and the dev bit will scare away any corp user. -- Nicolas Mailhot ___ 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: Updated review trackers pages
Il 07/04/20 17:31, Till Hofmann ha scritto:
>
> It looks like 1821497 [1] is displayed incorrectly (currently at the
> bottom of the page), maybe bccause of the unusual title ("Review
> Request: - ")?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1821497
Thanks, I've just pushed the fix for that.
Mattia
___
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: Modularity Survey
(I had several replies to Adam, but I ultimately got stuck finding supporting URLs until I revisited it this morning.) IANAL. - Original Message - > From: "Kamil Paral" > To: "Development discussions related to Fedora" > > Sent: Wednesday, April 8, 2020 4:25:55 AM > Subject: Re: Modularity Survey > > On Tue, Apr 7, 2020 at 7:22 PM Adam Williamson > wrote: > > > On Tue, 2020-04-07 at 13:12 -0400, Alex Scheel wrote: > > > I'm sure we can trust that Red Hat did its > > > > > > due diligence and Google isn't using responses to a customer's form to > > > > > > track those taking the survey. > > > > I don't really know why you'd think anyone can trust that. Google > > tracks everyone everywhere as hard as it can. It's what Google *does*. > > > > But I didn't actually suggest it's Terribly Awful to run this survey > > through Google. I just said the privacy declaration seems to be wrong. > > > > I personally considered it quite clear that the intended meaning was that > they are not giving the data away to anyone external deliberately. Your > responses will be read and understood by a very small group of people and > not published in raw form. Yes there are servers and software providers > along the way. But this way you could also include the ISPs who also are > not prevented from snooping in your packets (and it's trivial at least for > plain text emails). And even if they provided a "direct" way to send your > responses to their email, and we ignored the ISPs, still, Google is the > email provider for most RedHatters. So there's no improvement at all. > > I'm not saying we shouldn't talk about it, but the points mentioned are > common for most data submissions anywhere. I don't think it was the core of > the message. :-) It is tricky trying to pin down what Google does, on the outside, without any knowledge of what contracts actually got negotiated. There is an undated white paper which directly discusses it: https://gsuite.google.com/learn-more/security/security-whitepaper/page-6.html#no-advertising The only date mentioned there is 2014. Coincidentally, the 2014 Google Apps privacy policy also explicitly called it out: https://gsuite.google.com/intl/en_us/terms/2014/2/premier_terms_ie.html I tried looking at the new terms link on gsuite's page: https://www.google.com/intl/en/policies/terms/ But that just redirects to the generic, Google-wide page: https://policies.google.com/terms?hl=en Which is geared more towards consumers than enterprises. Neither "enterprise" nor "premier" appear. On the list of apps page: https://policies.google.com/terms/service-specific?hl=en There's a link here: https://www.google.com/drive/terms-of-service/?hl=en You can control who sees ads even, in a gsuite account, so maybe that's sufficient: https://support.google.com/a/answer/6304811?hl=en There's a marketing piece from 2017 that alleges that none of gsuite (including their gmail for gsuite!) gets scanned for ads: https://www.blog.google/products/gmail/g-suite-gains-traction-in-the-enterprise-g-suites-gmail-and-consumer-gmail-to-more-closely-align/ I think we can agree that--at one point in time (2014-2017)--Google's position was that they aren't scanning gsuite content. I'll make the assumption that, were this to have changed, a number of large businesses would've been upset and there would've been media reports and potentially legal proceedings. I haven't found any. :-) My 2c. - Alex Not delivered by GMail ;-) > > ___ > 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: OpenSSL 3.0
On Wed, Apr 8, 2020 at 8:14 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Apr 07, 2020 at 05:31:39PM -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/OpenSSL3.0 > > There was a plan to make the licensing more permissive in 3.0. > Did this happen in the end? > OpenSSL is now under the Apache Software License version 2.0 with no exceptions. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-32-20200408.0 compose check report
No missing expected images. Failed openQA tests: 1/8 (x86_64) Old failures (same test failed in Fedora-IoT-32-20200407.0): ID: 570254 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/570254 Passed openQA tests: 7/8 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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: Rawhide update from side tag pending for 2 days
Oh actually it's just started being pushed to stable. Thanks all. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ 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: OpenSSL 3.0
On Tue, Apr 07, 2020 at 05:31:39PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/OpenSSL3.0 There was a plan to make the licensing more permissive in 3.0. Did this happen in the end? Zbyszek ___ 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: Rawhide update from side tag pending for 2 days
On Wed, Apr 08, 2020 at 01:43:37PM +0200, Clement Verna wrote: > On Wed, 8 Apr 2020 at 13:15, Richard W.M. Jones wrote: > > > On Wed, Apr 08, 2020 at 11:57:27AM +0200, Clement Verna wrote: > > > >> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > koji untag f3x-build-side-n offending-nvr > > Once the builds are not in the tag, you still need to edit the update and > refresh the list of builds (There is a refresh/update button next to the > name of the side tag in the edit update from). That will fetch the list of > builds in the side tag. Thanks - I believe I've been able to do that now. The update is still in pending, but I'll leave it for a bit. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: Rawhide update from side tag pending for 2 days
On Wed, Apr 08, 2020 at 01:41:23PM +0200, Fabio Valentini wrote: > On Wed, Apr 8, 2020 at 11:58 AM Clement Verna > wrote: > > > > > > > > On Wed, 8 Apr 2020 at 11:38, Fabio Valentini wrote: > >> > >> On Wed, Apr 8, 2020, 11:27 Richard W.M. Jones wrote: > >>> > >>> On Tue, Apr 07, 2020 at 05:36:44PM -0400, Mohan Boddu wrote: > >>> > On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones > >>> > wrote: > >>> > > > >>> > > > >>> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > >>> > > >>> > I guess it should be a fixed in bodhi. But for now you can remove the > >>> > builds that it's complaining about in the update. > >>> > > >>> > https://github.com/fedora-infra/bodhi/issues/3991 > >>> > >>> So it is complaining: > >>> > >>> "This update cannot be pushed to stable. These builds > >>> brltty-6.0-14.fc33, graphviz-2.42.2-10.fc33 have a more recent build > >>> in koji's f33 tag." > >>> > >>> Those builds could just be removed before pushing. But I don't see a > >>> way to remove the builds from the UI. > >>> > >>> (This update took 3 days of work to create so I _really_ do not want > >>> to have to build the whole thing again.) > >> > >> > >> You should be able to run > >> > >> koji untag f3x-build-side-n offending-nvr > >> > >> for every package that's blocking the update. > > > > > > That will not work, since Bodhi does not react on changes from koji the > > update will still be stuck in Pending > > > > You need to edit the update and remove these builds. You can click on the > > "edit" button on the left side of the update status, then you will have a > > list builds with an "x" on the right side of each build. Clicking on that > > 'x' will remove the build from the update (see attached screenshot). > > > > Otherwise you can use the bodhi updates edit --removebuilds command, see > > man page > > https://bodhi.fedoraproject.org/docs/user/man_pages/bodhi.html#updates > > Nope, that won't work - you can't edit builds for updates that were > created from side tags - neither from the Web UI (no buttons), nor > from the API / CLI ... - they only have the "from_tag" attribute, but > it's currently impossible (as far as I can tell) to "refresh" those > side tag updates :/ That's why I suggested untagging in koji. But if > bodhi doesn't see those changes, that won't work either There is or was a button to refresh the side-tag updates. The idea being that you indeed untag from the side-tag and refresh the update so that the list of builds can be updated/refreshed. If we're not showing that refresh button that sounds like a bug :s Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rawhide update from side tag pending for 2 days
On Wed, 8 Apr 2020 at 13:42, Fabio Valentini wrote: > On Wed, Apr 8, 2020 at 11:58 AM Clement Verna > wrote: > > > > > > > > On Wed, 8 Apr 2020 at 11:38, Fabio Valentini > wrote: > >> > >> On Wed, Apr 8, 2020, 11:27 Richard W.M. Jones > wrote: > >>> > >>> On Tue, Apr 07, 2020 at 05:36:44PM -0400, Mohan Boddu wrote: > >>> > On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones > wrote: > >>> > > > >>> > > > >>> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > >>> > > >>> > I guess it should be a fixed in bodhi. But for now you can remove the > >>> > builds that it's complaining about in the update. > >>> > > >>> > https://github.com/fedora-infra/bodhi/issues/3991 > >>> > >>> So it is complaining: > >>> > >>> "This update cannot be pushed to stable. These builds > >>> brltty-6.0-14.fc33, graphviz-2.42.2-10.fc33 have a more recent build > >>> in koji's f33 tag." > >>> > >>> Those builds could just be removed before pushing. But I don't see a > >>> way to remove the builds from the UI. > >>> > >>> (This update took 3 days of work to create so I _really_ do not want > >>> to have to build the whole thing again.) > >> > >> > >> You should be able to run > >> > >> koji untag f3x-build-side-n offending-nvr > >> > >> for every package that's blocking the update. > > > > > > That will not work, since Bodhi does not react on changes from koji the > update will still be stuck in Pending > > > > You need to edit the update and remove these builds. You can click on > the "edit" button on the left side of the update status, then you will have > a list builds with an "x" on the right side of each build. Clicking on that > 'x' will remove the build from the update (see attached screenshot). > > > > Otherwise you can use the bodhi updates edit --removebuilds command, see > man page > https://bodhi.fedoraproject.org/docs/user/man_pages/bodhi.html#updates > > Nope, that won't work - you can't edit builds for updates that were > created from side tags - neither from the Web UI (no buttons), nor > from the API / CLI ... - they only have the "from_tag" attribute, but > it's currently impossible (as far as I can tell) to "refresh" those > side tag updates :/ That's why I suggested untagging in koji. But if > bodhi doesn't see those changes, that won't work either > Yeah I skipped the fact that the builds were in the side tag, so indeed that needs to be done in koji, then edit the update and refresh the list of builds from the UI. I don't think the CLI supports that currently. > > Fabio > > >> > >> Fabio > >> > >>> > >>> Rich. > >>> > >>> -- > >>> Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > >>> Read my programming and virtualization blog: http://rwmj.wordpress.com > >>> libguestfs lets you edit virtual machines. Supports shell scripting, > >>> bindings from many languages. http://libguestfs.org > >>> ___ > >>> devel mailing list -- devel@lists.fedoraproject.org > >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >>> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >>> List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > >>> List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > >> > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > ___ > > 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 > ___ 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/
Re: Rawhide update from side tag pending for 2 days
On Wed, 8 Apr 2020 at 13:15, Richard W.M. Jones wrote: > On Wed, Apr 08, 2020 at 11:57:27AM +0200, Clement Verna wrote: > > >> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > You need to edit the update and remove these builds. You can click on the > > "edit" button on the left side of the update status, then you will have a > > list builds with an "x" on the right side of each build. Clicking on that > > 'x' will remove the build from the update (see attached screenshot). > > I don't appear to have the "x" (nor the box with "Fedora 33"). > Permissions? > Hum ok sorry, so since the builds are in the side tag you indeed need to remove them from the tag as Fabio pointed out (should have read that more carefully). So koji untag f3x-build-side-n offending-nvr Once the builds are not in the tag, you still need to edit the update and refresh the list of builds (There is a refresh/update button next to the name of the side tag in the edit update from). That will fetch the list of builds in the side tag. Better documentation on how to do this is need :( > > > Otherwise you can use the bodhi updates edit --removebuilds command, see > > man page > > https://bodhi.fedoraproject.org/docs/user/man_pages/bodhi.html#updates > > $ bodhi updates edit --removebuilds > brltty-6.0-14.fc33,graphviz-2.42.2-10.fc33 FEDORA-2020-d120de33c5 > Cannot find release associated with build: alt-ergo-2.0.0-12.fc33, tags: > ['f33-build-side-20855'] > > (By the way that command failed, but still exited with code 0, which > is something that happens quite a lot across our tooling and causes me > endless trouble with automating things because I have to > "screen-scrape" output to find errors.) > Yes we have https://github.com/fedora-infra/bodhi/issues/3868, contributions welcomed :-) > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ 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: Rawhide update from side tag pending for 2 days
On Wed, Apr 8, 2020 at 11:58 AM Clement Verna wrote: > > > > On Wed, 8 Apr 2020 at 11:38, Fabio Valentini wrote: >> >> On Wed, Apr 8, 2020, 11:27 Richard W.M. Jones wrote: >>> >>> On Tue, Apr 07, 2020 at 05:36:44PM -0400, Mohan Boddu wrote: >>> > On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones >>> > wrote: >>> > > >>> > > >>> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 >>> > >>> > I guess it should be a fixed in bodhi. But for now you can remove the >>> > builds that it's complaining about in the update. >>> > >>> > https://github.com/fedora-infra/bodhi/issues/3991 >>> >>> So it is complaining: >>> >>> "This update cannot be pushed to stable. These builds >>> brltty-6.0-14.fc33, graphviz-2.42.2-10.fc33 have a more recent build >>> in koji's f33 tag." >>> >>> Those builds could just be removed before pushing. But I don't see a >>> way to remove the builds from the UI. >>> >>> (This update took 3 days of work to create so I _really_ do not want >>> to have to build the whole thing again.) >> >> >> You should be able to run >> >> koji untag f3x-build-side-n offending-nvr >> >> for every package that's blocking the update. > > > That will not work, since Bodhi does not react on changes from koji the > update will still be stuck in Pending > > You need to edit the update and remove these builds. You can click on the > "edit" button on the left side of the update status, then you will have a > list builds with an "x" on the right side of each build. Clicking on that 'x' > will remove the build from the update (see attached screenshot). > > Otherwise you can use the bodhi updates edit --removebuilds command, see man > page https://bodhi.fedoraproject.org/docs/user/man_pages/bodhi.html#updates Nope, that won't work - you can't edit builds for updates that were created from side tags - neither from the Web UI (no buttons), nor from the API / CLI ... - they only have the "from_tag" attribute, but it's currently impossible (as far as I can tell) to "refresh" those side tag updates :/ That's why I suggested untagging in koji. But if bodhi doesn't see those changes, that won't work either Fabio >> >> Fabio >> >>> >>> Rich. >>> >>> -- >>> Richard Jones, Virtualization Group, Red Hat >>> http://people.redhat.com/~rjones >>> Read my programming and virtualization blog: http://rwmj.wordpress.com >>> libguestfs lets you edit virtual machines. Supports shell scripting, >>> bindings from many languages. http://libguestfs.org >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > ___ > 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: Rawhide update from side tag pending for 2 days
On Wed, Apr 08, 2020 at 11:57:27AM +0200, Clement Verna wrote: > >> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > You need to edit the update and remove these builds. You can click on the > "edit" button on the left side of the update status, then you will have a > list builds with an "x" on the right side of each build. Clicking on that > 'x' will remove the build from the update (see attached screenshot). I don't appear to have the "x" (nor the box with "Fedora 33"). Permissions? > Otherwise you can use the bodhi updates edit --removebuilds command, see > man page > https://bodhi.fedoraproject.org/docs/user/man_pages/bodhi.html#updates $ bodhi updates edit --removebuilds brltty-6.0-14.fc33,graphviz-2.42.2-10.fc33 FEDORA-2020-d120de33c5 Cannot find release associated with build: alt-ergo-2.0.0-12.fc33, tags: ['f33-build-side-20855'] (By the way that command failed, but still exited with code 0, which is something that happens quite a lot across our tooling and causes me endless trouble with automating things because I have to "screen-scrape" output to find errors.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-31-20200408.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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: Packit-as-a-Service case studies and tips
On 08. 04. 20 12:26, Ernestas Kulik wrote: As someone who also maintains the code for multiple packages, I say tough luck. The workflow for keeping upstream changes buildable (and having the ability to test the changes) and downstream package specification in sync with said changes could not be worse currently. Packit solves that for me*and* gives me the ability to pull in whatever was done downstream. As someone who routinely does mass changes across the entire collection I appreciate you pull in whatever was done downstream. But putting the spec to upstream usually means this part is neglected. In other words, if you are prepared to manually sync the 2 diverging spec files, feel free to keep your spec files on the Moon as far as I am concerned, but suggesting to other maintainers to maintain their Fedora spec files outside of Fedora without stressing this very important point is not helpful. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packit-as-a-Service case studies and tips
On Wed, 2020-04-08 at 11:39 +0200, Miro Hrončok wrote: > On 08. 04. 20 11:33, Tomas Tomecek wrote: > > > My questions are > > > * How to manage a RPM spec file on the upstream repository, > > > synchronizing it with Fedora rawhide's one. > > Ideally, you'd maintain the spec upstream and packit will copy [1] > > it > > for you when you perform releases. > > Once again I would like to point out that the canonical source of the > spec files > in Fedora is the Fedora git. Copying upstream specfiles to Fedora via > automation > and saying "ideally, you'd maintain the spec upstream" goes against > this principle. > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenanc As someone who also maintains the code for multiple packages, I say tough luck. The workflow for keeping upstream changes buildable (and having the ability to test the changes) and downstream package specification in sync with said changes could not be worse currently. Packit solves that for me *and* gives me the ability to pull in whatever was done downstream. -- Ernestas Kulik Software Engineer Base Operating Systems - Core Services - ABRT Red Hat Czech, s.r.o. ___ 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: Corrupt RPM package in Fedora 31 compose: perf-debuginfo-5.5.9-200.fc31.x86_64
On 4/6/20 1:14 PM, Florian Weimer wrote: Installation fails like this: Running transaction Preparing: 1/1 Installing : perf-debuginfo-5.5.15-200.fc31.x86_64 1/1 Error unpacking rpm package perf-debuginfo-5.5.15-200.fc31.x86_64 Verifying: perf-debuginfo-5.5.15-200.fc31.x86_64 1/1 The RPM headers look okay, but the payload seems to be missing completely. perf-debuginfo-5.5.9-200.fc31.x86_64 seems to be affected as well, so this might be a deterministic issue. 8-( As corrupt rpm packages tend to get people edgy, here's the short summary of what this was about: kernel-tools.spec had inherited a manual perf-debuginfo sub-package from the kernel.spec, but unlike the kernel itself it has automatic debuginfo generation enabled. These silently clash and cause said debuginfo package tobe written twice, the result being a timing dependent coin-toss. So the rpm bug is that it doesn't cleanly error out on this situation, but it's nothing more serious than a funny little corner-case with packages doing their own debuginfo sub-packaging. - Panu - ___ 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: Announcing bugzilla overrides coming to dist-git (stg)
On Wed, Apr 08, 2020 at 11:56:01AM +0200, Miro Hrončok wrote: > On 17. 03. 20 14:45, Pierre-Yves Chibon wrote: > > > > If you are logged in and on a package where you have admin rights, > > > > there should > > > > be an "update" button underneath, clicking it makes a pop-up (a modal) > > > > appear, > > > > in which you can update the settings. > > > It appears you need to be main admin to do this. Is that intended? > > Reading the code it is definitely intended: > > https://pagure.io/pagure-dist-git/blob/master/f/pagure_distgit/plugin.py#_417 > > but I guess we could relax this to all project admins. > > May I suggest that members of the cvsadmin group should be able to change > this as well? > > I can change the main admin but not the bugizlla assignee which is kinda > weird. > > I am able to get the thing done by making myself the main admin, doing it > and giving the package back to the original owner, but it feels silly and > overcomplicated. That is a good point > Should I file a ticket at https://pagure.io/pagure-dist-git/ ? Please yes :) Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rawhide update from side tag pending for 2 days
On Wed, 8 Apr 2020 at 11:29, Richard W.M. Jones wrote: > On Wed, Apr 08, 2020 at 08:53:38AM +0200, Igor Gnatenko wrote: > > I agree, if this would not happen then everything would just blow up. > > Wouldn't the lower NVR builds simply be ignored? > The merging a side tag is not considering NVRs but the date the build was done. Bodhi just checks if a there is a more recent build in the rawhide buildroot, if that is the case it does not try to be too smart about it and let a human find out what is the best thing to do :-). The logic was taken from how releng is merging side tag, the human part of finding out what needs to be done was then I guess done by a release engineer. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ > 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: Rawhide update from side tag pending for 2 days
On Wed, 8 Apr 2020 at 11:38, Fabio Valentini wrote: > On Wed, Apr 8, 2020, 11:27 Richard W.M. Jones wrote: > >> On Tue, Apr 07, 2020 at 05:36:44PM -0400, Mohan Boddu wrote: >> > On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones >> wrote: >> > > >> > > >> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 >> > >> > I guess it should be a fixed in bodhi. But for now you can remove the >> > builds that it's complaining about in the update. >> > >> > https://github.com/fedora-infra/bodhi/issues/3991 >> >> So it is complaining: >> >> "This update cannot be pushed to stable. These builds >> brltty-6.0-14.fc33, graphviz-2.42.2-10.fc33 have a more recent build >> in koji's f33 tag." >> >> Those builds could just be removed before pushing. But I don't see a >> way to remove the builds from the UI. >> >> (This update took 3 days of work to create so I _really_ do not want >> to have to build the whole thing again.) >> > > You should be able to run > > koji untag f3x-build-side-n offending-nvr > > for every package that's blocking the update. > That will not work, since Bodhi does not react on changes from koji the update will still be stuck in Pending You need to edit the update and remove these builds. You can click on the "edit" button on the left side of the update status, then you will have a list builds with an "x" on the right side of each build. Clicking on that 'x' will remove the build from the update (see attached screenshot). Otherwise you can use the bodhi updates edit --removebuilds command, see man page https://bodhi.fedoraproject.org/docs/user/man_pages/bodhi.html#updates > Fabio > > >> Rich. >> >> -- >> Richard Jones, Virtualization Group, Red Hat >> http://people.redhat.com/~rjones >> Read my programming and virtualization blog: http://rwmj.wordpress.com >> libguestfs lets you edit virtual machines. Supports shell scripting, >> bindings from many languages. http://libguestfs.org >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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: Announcing bugzilla overrides coming to dist-git (stg)
On 17. 03. 20 14:45, Pierre-Yves Chibon wrote: If you are logged in and on a package where you have admin rights, there should be an "update" button underneath, clicking it makes a pop-up (a modal) appear, in which you can update the settings. It appears you need to be main admin to do this. Is that intended? Reading the code it is definitely intended: https://pagure.io/pagure-dist-git/blob/master/f/pagure_distgit/plugin.py#_417 but I guess we could relax this to all project admins. May I suggest that members of the cvsadmin group should be able to change this as well? I can change the main admin but not the bugizlla assignee which is kinda weird. I am able to get the thing done by making myself the main admin, doing it and giving the package back to the original owner, but it feels silly and overcomplicated. Should I file a ticket at https://pagure.io/pagure-dist-git/ ? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packit-as-a-Service case studies and tips
On 08. 04. 20 11:33, Tomas Tomecek wrote: My questions are * How to manage a RPM spec file on the upstream repository, synchronizing it with Fedora rawhide's one. Ideally, you'd maintain the spec upstream and packit will copy [1] it for you when you perform releases. Once again I would like to point out that the canonical source of the spec files in Fedora is the Fedora git. Copying upstream specfiles to Fedora via automation and saying "ideally, you'd maintain the spec upstream" goes against this principle. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenanc -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rawhide update from side tag pending for 2 days
On Wed, Apr 8, 2020, 11:27 Richard W.M. Jones wrote: > On Tue, Apr 07, 2020 at 05:36:44PM -0400, Mohan Boddu wrote: > > On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones > wrote: > > > > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > > > I guess it should be a fixed in bodhi. But for now you can remove the > > builds that it's complaining about in the update. > > > > https://github.com/fedora-infra/bodhi/issues/3991 > > So it is complaining: > > "This update cannot be pushed to stable. These builds > brltty-6.0-14.fc33, graphviz-2.42.2-10.fc33 have a more recent build > in koji's f33 tag." > > Those builds could just be removed before pushing. But I don't see a > way to remove the builds from the UI. > > (This update took 3 days of work to create so I _really_ do not want > to have to build the whole thing again.) > You should be able to run koji untag f3x-build-side-n offending-nvr for every package that's blocking the update. Fabio > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > libguestfs lets you edit virtual machines. Supports shell scripting, > bindings from many languages. http://libguestfs.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packit-as-a-Service case studies and tips
Hi Jun, thanks for reaching out! I'd suggest CCing someone from our team in future to make sure we see your message. It's good though you started the discussion on fedora-devel. On Thu, Apr 2, 2020 at 8:54 PM Jun Aruga wrote: > > I am considering using Packit-as-a-Service [1] for an upstream > project, as the maintainer of the project suggested managing the RPM > spec file on the upstream's repository in Github. > > Could you tell me some case studies of the upstream project using > Packit-as-a-Service? > I know rebase-helper [2] is using it. There is a bunch of projects who are already integrated with packit-service at this point: * https://github.com/beaker-project/restraint/blob/master/.packit.yaml * https://github.com/abrt/faf/blob/master/.packit.yml * https://github.com/containerbuildsystem/atomic-reactor/blob/master/.packit.yaml * https://github.com/fedora-modularity/libmodulemd/blob/master/.packit.yml * https://github.com/packit-service/ogr/blob/master/.packit.yaml (and us obviously) * ... > What I want to do is > * to check the RPM spec file at the pull-request timing on GitHub, > building it on specified build targets (rawhide or fNN). This the basic use case which packit is helping to solve. > My questions are > * How to manage a RPM spec file on the upstream repository, > synchronizing it with Fedora rawhide's one. Ideally, you'd maintain the spec upstream and packit will copy [1] it for you when you perform releases. > For example, in case of rawhide, the RPM spec file's release version > is sometimes automatically updated. > I am thinking of managing the RPM spec file on the upstream without > %changelog to synchronize it easily. Packit does not sync changelogs b/w the two places because they tend to differ. As for release number -- those can get out of sync. Luckily everything is git so changes can be seen easily and reverted or updated. > * Is it possible to manage the RPM spec file including %PatchN and the > patch file on the upstream repository? It is, just include the patch file in the repo. Please let us know if you need any help with setting everything up. [1] https://packit.dev/docs/configuration/#supported-jobs (propose_downstream job) ___ 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: Rawhide update from side tag pending for 2 days
On Wed, Apr 08, 2020 at 08:53:38AM +0200, Igor Gnatenko wrote: > I agree, if this would not happen then everything would just blow up. Wouldn't the lower NVR builds simply be ignored? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: Rawhide update from side tag pending for 2 days
On Tue, Apr 07, 2020 at 05:36:44PM -0400, Mohan Boddu wrote: > On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones wrote: > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > I guess it should be a fixed in bodhi. But for now you can remove the > builds that it's complaining about in the update. > > https://github.com/fedora-infra/bodhi/issues/3991 So it is complaining: "This update cannot be pushed to stable. These builds brltty-6.0-14.fc33, graphviz-2.42.2-10.fc33 have a more recent build in koji's f33 tag." Those builds could just be removed before pushing. But I don't see a way to remove the builds from the UI. (This update took 3 days of work to create so I _really_ do not want to have to build the whole thing again.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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 Self-Contained Change proposal: Network Time Security
On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote: > It doesn't make much sense to me for this to default to on if we still > "trust" the DNS servers provided over DHCP. What is the issue with using untrusted DNS servers here? An NTS client is supposed to verify the certificates. Local MITM attackers shouldn't be able to force the client to synchronize to a different NTP server. (Of course, they can always disable the synchronization.) > Additionally, it's not clear to > me from the proposal what it would take for an NTP server provided over DHCP > to be "trusted", or what a "trusted network" is. Are only NTS-enabled > sources to be trusted? Generally, yes. What I meant, if someone for example had at home a stratum 1 server (e.g. synchronized to GPS) and they trusted everything and everyone in their local network, it would make sense to still use the server (without NTS) in addition to any external time servers authenticated by NTS. The question is if we need to change the default value of the PEERNTP option. There could be a new default which adds the servers provided by DHCP only if chronyd is not using any servers with enabled authentication. > What becomes of the old default fedora.pool.ntp.org? It would still work, even if we didn't use it by default. The name is just an alias for pool.ntp.org. The servers used in the current default configuration are not run by Fedora. > Finally, from a purely personal standpoint, I don't like seeing yet more > infrastructure being handed over to a hyperscaler like Cloudflare (see also > DoH in Firefox). I would be less opposed to this being default if > pool.ntp.org found a way to support it. Yes, that's a valid point, which we need to consider. I don't have a strong opinion either way. I'd like to see pool.ntp.org to support NTS. But I'm not sure if the trust of not being attacked will be comparable to a single entity running the servers, even if the pool has a sufficient number of NTS-enabled servers and implements some mitigations like mixing servers from different countries. -- Miroslav Lichvar ___ 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: Packit-as-a-Service case studies and tips
> * How to manage a RPM spec file on the upstream repository, synchronizing it with Fedora rawhide's one. As my first step, I am trying to use Packit, having separately managed the RPM spec file that is only used to run the %check section on the Fedora scratch build at the pull-request in the upstream. Seeing the resources such as https://github.com/packit-service/packit . -- Jun | He - His - Him ___ 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: OpenSSL 3.0
On 07. 04. 20 23:31, Ben Cotton wrote: * Proposal owners: Provide a compat-openssl11 package, identify dependent packages, provide the rebased openssl package, work with dependent package owners on rebuilds. Thanks for doing this. Will compat-openssl11-devel be provided? For how long you intent to support it? E.g. I don't see Python 2 ever supporting openssl 3, that's why I'm asking. (Replied this sooner, but accidentally to devel-announce.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity Survey
On Tue, Apr 7, 2020 at 7:22 PM Adam Williamson wrote: > On Tue, 2020-04-07 at 13:12 -0400, Alex Scheel wrote: > > I'm sure we can trust that Red Hat did its > > > > due diligence and Google isn't using responses to a customer's form to > > > > track those taking the survey. > > I don't really know why you'd think anyone can trust that. Google > tracks everyone everywhere as hard as it can. It's what Google *does*. > > But I didn't actually suggest it's Terribly Awful to run this survey > through Google. I just said the privacy declaration seems to be wrong. > I personally considered it quite clear that the intended meaning was that they are not giving the data away to anyone external deliberately. Your responses will be read and understood by a very small group of people and not published in raw form. Yes there are servers and software providers along the way. But this way you could also include the ISPs who also are not prevented from snooping in your packets (and it's trivial at least for plain text emails). And even if they provided a "direct" way to send your responses to their email, and we ignored the ISPs, still, Google is the email provider for most RedHatters. So there's no improvement at all. I'm not saying we shouldn't talk about it, but the points mentioned are common for most data submissions anywhere. I don't think it was the core of the message. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-30-20200408.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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: Detecting when building under mock?
Dne 07. 04. 20 v 17:43 Scott Talbert napsal(a): > Is there a recommended way for detecting when a package is being built under > mock? In Mock, we try as much as possible mimic normal system. So - no, there is no way I can recommend. > I have a package where some tests > fail due to various things not being present in a mock container, e.g, > /dev/log doesn't exist. I can just disable these > tests downstream, but upstream might take a change if I can wrap them in a > "if !mock" condition. /dev/log is handled by journalctl (but not owned, which is likely packaging bug). In the buildchroot the systemd (and therefore journalctl) is not running. IMHO you should check if system logging is enabled - which is beyond my knowledge. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ 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: ELN Buildroot and Compose V4
Dne 07. 04. 20 v 20:55 Stephen Gallagher napsal(a): > On Mon, Apr 6, 2020 at 5:53 PM Stephen Gallagher > wrote: > > I've just published a fourth version[1] of the ELN proposal. With a > > lot of input from Miro Hrončok, I think I've finally been able to > > clarify some of the points that we were getting hung up on. > > Up to this point, we've been a little vague on what "there will > eventually be a way to maintain a fork of your package that will go > into RHEL" actually means. I can finally make this clearer: > > - From now until RHEL 9 Alpha ships, work that is intended for > inclusion in RHEL 9 should be contributed to Fedora Rawhide (later, > F34 branch). Then we are back to beginning. If the change is not acceptable for Rawhide, then there is no place for it. But honestly, what I really don't understand is that if you are going to open PR against Rawhide (assuming that you are always going to use PRs, because you can run CI above them), you have to have (fork and) branch already. So why don't you formalize this at least? E.g. "If there is ELN change proposed for Rawhide, then the PR is always opened from (ELN fork and) ELN branch." And voila, we have the (fork and) branch! We have a place where the changes can live, waiting for being (not) accepted. If nothing else, the changes for ELN would be discoverable, even though you would no used them anywhere unless merged into Rawhide. Vít > After Alpha ships, a branch of CentOS Stream will open > that will accept contributions towards RHEL 9 Beta. > > I'm pretty excited about this, myself. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Nvidia 440.82 came out today
> On Tue, 2020-04-07 at 20:55 -0400, Paul Dufresne via devel wrote: > you could discuss it on their mailing lists etc. There is no need to do that as rpmfusion has already been updated to 440.82 ___ 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: Detecting when building under mock?
On Tue, Apr 07, 2020 at 02:51:43PM -0400, Scott Talbert wrote: > On Tue, 7 Apr 2020, Paul Howarth wrote: > > > > Is there a recommended way for detecting when a package is being > > > built under mock? I have a package where some tests fail due to > > > various things not being present in a mock container, e.g, /dev/log > > > doesn't exist. I can just disable these tests downstream, but > > > upstream might take a change if I can wrap them in a "if !mock" > > > condition. > > > > Why not test for the presence of /dev/log before running such tests? > > Well, in the particular case of that test, checking whether /dev/log exists > *is* the test. > Then it's a bug in the test. Since when /dev/log must exist on a system? You can have various environments that are missing the socket. Mock is jist one of them. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [ANN] python-hypothesis 5.8.0 in fc33, fc32
On 08. 04. 20 4:22, Michel Alexandre Salim wrote:
Hi all,
I just updated python-hypothesis to the latest 5.8.0 version. It should be fine
for Rawhide, but for Fedora 32 it's probably worth testing (since the previous
version we have in the repo is a bit behind -- 4.23.8).
I'm putting it as a buildroot override in case maintainers for the dependent
packages want to verify this works as expected:
https://bodhi.fedoraproject.org/overrides/python-hypothesis-5.8.0-2.fc32
$ sudo dnf repoquery --whatrequires python3-hypothesis
python3-argon2-cffi-0:19.2.0-2.fc32.x86_64
python3-hs-dbus-signature-0:0.06-6.fc32.noarch
python3-hypothesis-fspaths-0:0.1-5.fc32.noarch
There is also:
$ repoquery --repo=rawhide{,-source} --whatrequires python3-hypothesis
pytest-0:4.6.9-2.fc32.src
python-CommonMark-0:0.9.0-5.fc32.src
python-MDAnalysis-0:0.20.1-2.fc33.src
python-anyio-0:1.2.3-2.fc32.src
python-argon2-cffi-0:19.2.0-2.fc32.src
python-astropy-healpix-0:0.4-6.fc32.src
python-attrs-0:19.3.0-2.fc32.src
python-binaryornot-0:0.4.4-4.fc32.src
python-cryptography-0:2.8-3.fc32.src
python-dateutil-1:2.8.0-8.fc32.src
python-dbus-client-gen-0:0.4-6.fc32.src
python-dbus-signature-pyparsing-0:0.03-9.fc32.src
python-h2-0:3.2.0-2.fc33.src
python-hpack-0:3.0.0-9.fc32.src
python-hs-dbus-signature-0:0.06-6.fc32.src
python-hypothesis-fspaths-0:0.1-5.fc32.src
python-icalendar-0:4.0.5-1.fc33.src
python-into-dbus-python-0:0.07-3.fc32.src
python-justbytes-0:0.11-10.fc32.src
python-mutagen-0:1.43.0-2.fc32.src
python-natsort-0:7.0.1-1.fc33.src
python-parver-0:0.3.0-1.fc33.src
python-pikepdf-0:1.10.4-1.fc33.src
python-priority-0:1.3.0-9.fc32.src
python-pynacl-0:1.3.0-6.fc32.src
python-pyrsistent-0:0.15.7-2.fc32.src
python-pytest-trio-0:0.5.2-2.fc32.src
python-rasterio-0:1.1.3-2.fc33.src
python-snuggs-0:1.4.7-2.fc32.src
python-vistir-0:0.4.3-5.fc32.src
python-werkzeug-0:0.16.0-2.fc32.src
python3-argon2-cffi-0:19.2.0-2.fc32.x86_64
python3-hs-dbus-signature-0:0.06-6.fc32.noarch
python3-hypothesis-fspaths-0:0.1-5.fc32.noarch
python3-pytest-asyncio-0:0.10.0-5.fc32.src
subunit-0:1.4.0-1.fc33.src
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
