Unresponsive maintainer: mbaldessari
Hello, Does anyone here know how to contact mbaldessari? I can't get him to answer on RHBZ#1640405 [0]. Output of `fedora_active_user.py`: ``` Last login in FAS: mbaldessari 2018-06-01 Last action on koji: Tue, 04 Dec 2018 package list entry revoked: beets in trashcan by oscar Last package update on bodhi: 2018-07-31 20:17:46 on package shorewall-5.2.0.4-1.fc28 Last actions performed according to fedmsg: - pvikt...@redhat.com updated 'cc' on RHBZ#1605799 'python-oauth2client: FTBFS in Fedora raw...' on 2019-01-08 16:01:07 () - andreas.kri...@univie.ac.at updated nothing on RHBZ#1663924 'vdirsyncer has unsatisfied requirement c...' on 2019-01-07 11:13:00 () - mhron...@redhat.com updated nothing on RHBZ#1663843 'python-parsedatetime: Remove (sub)packag...' on 2019-01-07 09:20:22 () - redhat-bugzi...@krp.org.uk updated nothing on RHBZ#1640405 'vdirsyncer broken on Fedora 29' on 2018-12-21 21:33:55 () - amah...@redhat.com updated 'cc' on RHBZ#1640405 'vdirsyncer broken on Fedora 29' on 2018-12-20 16:21:52 () ERROR:active-user:This shouldn't happen. - number80's meeting titled "RDO meeting - 2018-12-19" ended in #rdo on 2018-12-19 16:40:36 ``` [0] https://bugzilla.redhat.com/show_bug.cgi?id=1640405 (vdirsyncer broken on Fedora 29) Thanks, -- Timothée 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unresponsive maintainer: mbaldessari
Hi Timothée, sorry am a bit swamped with work. I should be able to get to them week. cheers, Michele On Tue, Jan 15, 2019 at 09:18:39AM +0100, Timothée Floure wrote: > Hello, > > Does anyone here know how to contact mbaldessari? I can't get him to answer on > RHBZ#1640405 [0]. > > Output of `fedora_active_user.py`: > > ``` > Last login in FAS: >mbaldessari 2018-06-01 > Last action on koji: >Tue, 04 Dec 2018 package list entry revoked: beets in trashcan by oscar > Last package update on bodhi: >2018-07-31 20:17:46 on package shorewall-5.2.0.4-1.fc28 > Last actions performed according to fedmsg: > - pvikt...@redhat.com updated 'cc' on RHBZ#1605799 'python-oauth2client: > FTBFS in Fedora raw...' on 2019-01-08 16:01:07 () > - andreas.kri...@univie.ac.at updated nothing on RHBZ#1663924 'vdirsyncer > has unsatisfied requirement c...' on 2019-01-07 11:13:00 () > - mhron...@redhat.com updated nothing on RHBZ#1663843 > 'python-parsedatetime: Remove (sub)packag...' on 2019-01-07 09:20:22 () > - redhat-bugzi...@krp.org.uk updated nothing on RHBZ#1640405 'vdirsyncer > broken on Fedora 29' on 2018-12-21 21:33:55 () > - amah...@redhat.com updated 'cc' on RHBZ#1640405 'vdirsyncer broken on > Fedora 29' on 2018-12-20 16:21:52 () > ERROR:active-user:This shouldn't happen. > - number80's meeting titled "RDO meeting - 2018-12-19" ended in #rdo on > 2018-12-19 16:40:36 > ``` > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=1640405 (vdirsyncer broken on > Fedora 29) > > Thanks, > > -- > Timothée > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Michele Baldessari C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: libcrypt.so.1 (compatibility library for POSIX): Let encrypt, encrypt_r, setkey, setkey_r, and fcrypt return ENOSYS instead of performing any real operation
* Ben Cotton: > Remove real functionality from encrypt, encrypt_r, setkey, setkey_r, > and fcrypt from the libxcrypt.so.1 compatibility library and let those > functions set "errno" to "ENOSYS" when invoked. encrypt rewrites its argument in place, so this will leave the argument unencrypted. This does not seem a good idea, even if it's just DES. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
The "see-also" field in bugzilla
Hello, The bugzilla upgrade removed the "see-also" field which I found most useful. Would anyone have any tips on reproducing its functionality in the current version? A bug requesting that it be brought back has been closed as WONTFIX: https://bugzilla.redhat.com/show_bug.cgi?id=1661164 I've commented there also, but I'd like to learn how others go about it without "see-also". -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The "see-also" field in bugzilla
On 15/01/2019 10:21, Ankur Sinha wrote: The bugzilla upgrade removed the "see-also" field which I found most useful. Would anyone have any tips on reproducing its functionality in the current version? A bug requesting that it be brought back has been closed as WONTFIX: https://bugzilla.redhat.com/show_bug.cgi?id=1661164 I've commented there also, but I'd like to learn how others go about it without "see-also". I don't remember what see-also looked like, but there is still a field there (referred to somewhat cryptically as ET in the bug) for connecting a bug to an upstream bug via the "External Trackers" section. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The "see-also" field in bugzilla
* Ankur Sinha [15/01/2019 10:21] : > > I've commented there also, but I'd like to learn how others go about it > without "see-also". Is there anything you did with "see-also" that you can't do with the "External Trackers" feature? Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The "see-also" field in bugzilla
On Tue, Jan 15, 2019 10:33:34 +, Tom Hughes wrote: > On 15/01/2019 10:21, Ankur Sinha wrote: > > > The bugzilla upgrade removed the "see-also" field which I found most > > useful. Would anyone have any tips on reproducing its functionality in > > the current version? > > > > A bug requesting that it be brought back has been closed as WONTFIX: > > https://bugzilla.redhat.com/show_bug.cgi?id=1661164 > > > > I've commented there also, but I'd like to learn how others go about it > > without "see-also". > > I don't remember what see-also looked like, but there is still a field > there (referred to somewhat cryptically as ET in the bug) for connecting > a bug to an upstream bug via the "External Trackers" section. Aaah! It's very counter intuitive to call it "external trackers", but all of this seems to have been brought up in the other bug that is now linked to there: https://bugzilla.redhat.com/show_bug.cgi?id=1298053 -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The "see-also" field in bugzilla
On Tue, Jan 15, 2019 11:58:51 +0100, Emmanuel Seyman wrote: > * Ankur Sinha [15/01/2019 10:21] : > > > > I've commented there also, but I'd like to learn how others go about it > > without "see-also". > > Is there anything you did with "see-also" that you can't do with > the "External Trackers" feature? Yes. See the comments on this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1298053 -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The "see-also" field in bugzilla
On Tue, Jan 15, 2019 at 11:59 AM Emmanuel Seyman wrote: > * Ankur Sinha [15/01/2019 10:21] : > > > > I've commented there also, but I'd like to learn how others go about it > > without "see-also". > > Is there anything you did with "see-also" that you can't do with > the "External Trackers" feature? Unless I'm missing something, you have to use "External Trackers" on both sides. With "SeeAlso", you specified it in one bugzilla and it automatically showed in the referenced one. Also, linking two bugzillas together, because they are similar, or simply to "also see" something that might be related, can hardly be called external tracking. -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The "see-also" field in bugzilla
On Tue, Jan 15, 2019 12:45:11 +0100, Jan Synacek wrote: > On Tue, Jan 15, 2019 at 11:59 AM Emmanuel Seyman wrote: > > * Ankur Sinha [15/01/2019 10:21] : > > > > I've commented there also, but I'd like to learn how others go about it > > without "see-also". > > Is there anything you did with "see-also" that you can't do with > the "External Trackers" feature? > > > Unless I'm missing something, you have to use "External Trackers" on both > sides. With "SeeAlso", you specified it in one bugzilla and it automatically > showed in the referenced one. Also, linking two bugzillas together, because > they are similar, or simply to "also see" something that might be related, can > hardly be called external tracking. I agree. As upstream has suggested, I filed these RFEs in the meantime: - https://bugzilla.redhat.com/show_bug.cgi?id=1666266 - https://bugzilla.redhat.com/show_bug.cgi?id=1666269 -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The "see-also" field in bugzilla
* Jan Synacek [15/01/2019 12:45] : > > Unless I'm missing something, you have to use "External Trackers" on both > sides. With "SeeAlso", you specified it in one bugzilla and it > automatically showed in the referenced one. This only works if both bugs are in the same instance. There's never been inter-bugzilla-instances communication (thoough I've threatened the bugzilla deps to add this). Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 System-Wide Change proposal (update): DNF Better Counting (was: DNF UUID)
On Mo, 14.01.19 17:15, Ben Cotton (bcot...@redhat.com) wrote: > # Add a new "countme" variable. This variable will: > #* Start as a "true" value, > #* Reset to a "false" value the first time the client successfully > makes a request to Fedora mirror servers, and > #* Be reset to a "true" value after seven days. This works correctly if all clients do a dnf run at least once a week. Is this really expected? Maybe use this instead: "count=fresh" → this is the first dnf invocation on a fresh install "count=monthly" → this is used the first time in every 29.53 day cycle, except if this is a fresh install (i.e. count=fresh is sent instead) "count=weekly" → this is used the first time in every 7 day cycle, except if this is a fresh install or also the first time in the 29.53 day cycle (i.e. only if neither count=fresh nor count=monthly are sent) If neither of those three cases apply no argument is sent. The above allows to do stats: 1. systems active every week 2. systems active every month 3. systems that survive a week 4. systems that survive a month (And of course all stats derived from the above: systems that didn't survive the first week, and so on). Lennart -- Lennart Poettering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: libcrypt.so.1 (compatibility library for POSIX): Let encrypt, encrypt_r, setkey, setkey_r, and fcrypt return ENOSYS instead of performing any real operation
On Tue, 2019-01-15 at 10:39 +0100, Florian Weimer wrote: > * Ben Cotton: > > > Remove real functionality from encrypt, encrypt_r, setkey, setkey_r, > > and fcrypt from the libxcrypt.so.1 compatibility library and let those > > functions set "errno" to "ENOSYS" when invoked. > > encrypt rewrites its argument in place, so this will leave the argument > unencrypted. This does not seem a good idea, even if it's just DES. Maybe encrypt with AES and return an error anyway ? -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: libcrypt.so.1 (compatibility library for POSIX): Let encrypt, encrypt_r, setkey, setkey_r, and fcrypt return ENOSYS instead of performing any real operation
On 15/01/2019 13:42, Simo Sorce wrote: On Tue, 2019-01-15 at 10:39 +0100, Florian Weimer wrote: * Ben Cotton: Remove real functionality from encrypt, encrypt_r, setkey, setkey_r, and fcrypt from the libxcrypt.so.1 compatibility library and let those functions set "errno" to "ENOSYS" when invoked. encrypt rewrites its argument in place, so this will leave the argument unencrypted. This does not seem a good idea, even if it's just DES. Maybe encrypt with AES and return an error anyway ? Or just fill the buffer with some constant - zero or 0xdeadbeef or whatever = and return an error. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: libcrypt.so.1 (compatibility library for POSIX): Let encrypt, encrypt_r, setkey, setkey_r, and fcrypt return ENOSYS instead of performing any real operation
* Simo Sorce: > On Tue, 2019-01-15 at 10:39 +0100, Florian Weimer wrote: >> * Ben Cotton: >> >> > Remove real functionality from encrypt, encrypt_r, setkey, setkey_r, >> > and fcrypt from the libxcrypt.so.1 compatibility library and let those >> > functions set "errno" to "ENOSYS" when invoked. >> >> encrypt rewrites its argument in place, so this will leave the argument >> unencrypted. This does not seem a good idea, even if it's just DES. > > Maybe encrypt with AES and return an error anyway ? It's still only got a 56-bit key. AES would only make dictionary attacks easier because there are more efficient AES implementations than DES implementations. Maybe the stub implementation should just overwrite the argument with zeros. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: libcrypt.so.1 (compatibility library for POSIX): Let encrypt, encrypt_r, setkey, setkey_r, and fcrypt return ENOSYS instead of performing any real operation
On Tue, 2019-01-15 at 14:51 +0100, Florian Weimer wrote: > * Simo Sorce: > > > On Tue, 2019-01-15 at 10:39 +0100, Florian Weimer wrote: > > > * Ben Cotton: > > > > > > > Remove real functionality from encrypt, encrypt_r, setkey, setkey_r, > > > > and fcrypt from the libxcrypt.so.1 compatibility library and let those > > > > functions set "errno" to "ENOSYS" when invoked. > > > > > > encrypt rewrites its argument in place, so this will leave the argument > > > unencrypted. This does not seem a good idea, even if it's just DES. > > > > Maybe encrypt with AES and return an error anyway ? > > It's still only got a 56-bit key. AES would only make dictionary > attacks easier because there are more efficient AES implementations than > DES implementations. You could use a random key, but yeah if you need to simply make it inoperable just overwrite with random. > Maybe the stub implementation should just overwrite the argument with > zeros. I wouldn't overwrite with zeros because then it is clear the encryption failed and if it is used in non-orthodox ways could give an attacker a way to exploit the zeroing. (for example if someone uses it to encrypt a password, instead of hashing it and then compare to some stored value, then zeroing might be a bad choice as all invocations will always return the same value and would always compare "right") Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Organizing a "packager experience" objective and working group
On Thu, Jan 10, 2019 at 07:47:26PM -, Artur Iwicki wrote: > - Now that I've mentioned it, maybe we should add something like "fedpkg > fas-login"? Personally I've put "alias koji-init='kinit > my-fas-acco...@my-domain.org'" in my .bashrc, because looking up how to solve > the "koji says I'm unauthenticated" error got boring after the third time. IMHO you can take this one step further. Instead of telling that one is unauthenticted it should start the authentication and ask for credentials. Kind regards Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: libcrypt.so.1 (compatibility library for POSIX): Let encrypt, encrypt_r, setkey, setkey_r, and fcrypt return ENOSYS instead of performing any real operation
* Simo Sorce: >> Maybe the stub implementation should just overwrite the argument with >> zeros. > > I wouldn't overwrite with zeros because then it is clear the encryption > failed and if it is used in non-orthodox ways could give an attacker a > way to exploit the zeroing. > > (for example if someone uses it to encrypt a password, instead of > hashing it and then compare to some stored value, then zeroing might be > a bad choice as all invocations will always return the same value and > would always compare "right") That's a fair point. Overwriting with random data seems better. (There's precedent for doing that on decryption failures, too.) Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
rpmbuild: File listed twice (but only build-ids)
I'm working on the recent release of mythtv and everything compiled fine
until I got to the rpm packaging part which I got the following output:
File listed twice:
/usr/lib/.build-id/01/02700911bb4fe728258f16703a35d816ddb31f
File listed twice:
/usr/lib/.build-id/5f/dc725022956f8f935afc0d29ad91594f57ee6e
File listed twice:
/usr/lib/.build-id/67/82796d2132f1b0dc2f865d208297340b1e7005
File listed twice:
/usr/lib/.build-id/83/30ab4fd5e920cc992a734b234d62fc7895db0f
File listed twice:
/usr/lib/.build-id/94/1a02be6311015e5b7f7b1778d463475925b5bc
File listed twice:
/usr/lib/.build-id/ae/d6aef663c2c17307251cb23e598212ad41d3d8
File listed twice:
/usr/lib/.build-id/d9/dfc4a918c04b597302215241b783a1fb0ca84d
File listed twice:
/usr/lib/.build-id/e6/306d3c48dc40e9927d9408900cb773dda95c48
---
For one, the output isn't very useful so I shelled into the mock and looked
up the "offending files":
02700911bb4fe728258f16703a35d816ddb31f ->
../../../../usr/lib64/libmythavformat.so.58.12.100
dc725022956f8f935afc0d29ad91594f57ee6e ->
../../../../usr/lib64/libmythavdevice.so.58.3.100
82796d2132f1b0dc2f865d208297340b1e7005 ->
../../../../usr/lib64/libmythavcodec.so.58.18.100
30ab4fd5e920cc992a734b234d62fc7895db0f ->
../../../../usr/lib64/libmythswscale.so.5.1.100
1a02be6311015e5b7f7b1778d463475925b5bc ->
../../../../usr/lib64/libmythavutil.so.56.14.100
d6aef663c2c17307251cb23e598212ad41d3d8 ->
../../../../usr/lib64/libmythpostproc.so.55.1.100
dfc4a918c04b597302215241b783a1fb0ca84d ->
../../../../usr/lib64/libmythswresample.so.3.1.100
306d3c48dc40e9927d9408900cb773dda95c48 ->
../../../../usr/lib64/libmythavfilter.so.7.16.100
---
I looked through the spec file and can't find where it's being included
twice, and why only the build-ids are listed twice, not the libraries
themselves.
$ grep "%{_libdir}" rpmbuild/mythtv/SPECS/mythtv.spec
%dir %{_libdir}/mythtv
%{_libdir}/mythtv/filters/
%dir %{_libdir}/mythtv/plugins
%exclude %{_libdir}/libmythav*.so.*
%exclude %{_libdir}/libmythpostproc.so.*
%exclude %{_libdir}/libmythswscale.so.*
%exclude %{_libdir}/libmythswresample.so.*
%{_libdir}/*.so.*
%{_libdir}/*.so
%{_libdir}/libmythav*.so.*
%{_libdir}/libmythpostproc.so.*
%{_libdir}/libmythswscale.so.*
%{_libdir}/libmythswresample.so.*
%{_libdir}/mythtv/plugins/libmytharchive.so
%{_libdir}/mythtv/plugins/libmythbrowser.so
%{_libdir}/mythtv/plugins/libmythgallery.so
%{_libdir}/mythtv/plugins/libmythgame.so
%{_libdir}/mythtv/plugins/libmythmusic.so
%{_libdir}/mythtv/plugins/libmythnews.so
%{_libdir}/mythtv/plugins/libmythweather.so
%{_libdir}/mythtv/plugins/libmythzoneminder.so
%{_libdir}/mythtv/plugins/libmythnetvision.so
Is the %exclude just not working for the build-ids? That's all I can come
up with.
Help appreciated.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Rawhide-20190115.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 1 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 1/24 (i386), 10/132 (x86_64), 1/2 (arm) New failures (same test not failed in Rawhide-20190114.n.0): ID: 345063 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/345063 Old failures (same test failed in Rawhide-20190114.n.0): ID: 345049 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/345049 ID: 345056 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/345056 ID: 345057 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/345057 ID: 345068 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/345068 ID: 345080 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/345080 ID: 345084 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/345084 ID: 345106 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/345106 ID: 345141 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/345141 ID: 345142 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/345142 ID: 345143 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/345143 ID: 345151 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/345151 Soft failed openQA tests: 3/132 (x86_64), 5/24 (i386) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Rawhide-20190114.n.0): ID: 345060 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/345060 ID: 345061 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/345061 ID: 345065 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/345065 Old soft failures (same test soft failed in Rawhide-20190114.n.0): ID: 345041 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/345041 ID: 345042 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/345042 ID: 345134 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/345134 ID: 345158 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/345158 ID: 345159 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/345159 Passed openQA tests: 119/132 (x86_64), 18/24 (i386) New passes (same test not passed in Rawhide-20190114.n.0): ID: 345023 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/345023 ID: 345024 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/345024 ID: 345025 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/345025 ID: 345037 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/345037 ID: 345058 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/345058 ID: 345064 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/345064 ID: 345082 Test: x86_64 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/345082 ID: 345085 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/345085 ID: 345086 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/345086 ID: 345087 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/345087 ID: 345088 Test: x86_64 universal install_delete_pata URL: https://openqa.fedoraproject.org/tests/345088 ID: 345089 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/345089 ID: 345090 Test: x86_64 universal install_sata URL: https://openqa.fedoraproject.org/tests/345090 ID: 345091 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/345091 ID: 345093 Test: x86_64 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/345093 ID: 345094 Test: x86_64 universal install_multi URL: https://openqa.fedoraproject.org/tests/345094 ID: 345095 Test: x86_64 universal install_multi@uefi URL: https://ope
Re: rpmbuild: File listed twice (but only build-ids)
On 15/01/2019 14:41, Richard Shaw wrote:
Is the %exclude just not working for the build-ids? That's all I can
come up with.
Well it is working, but it doesn't exclude them because they
don't match any of the patterns.
Those excludes only match files in %{_libdir} not in the .build-id
directory underneath it.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rpmbuild: File listed twice (but only build-ids)
On Tue, Jan 15, 2019 at 7:42 AM Richard Shaw wrote: > Is the %exclude just not working for the build-ids? That's all I can come up > with. See: https://bugzilla.redhat.com/show_bug.cgi?id=878863 https://bugzilla.redhat.com/show_bug.cgi?id=1482698 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 System-Wide Change proposal (update): DNF Better Counting (was: DNF UUID)
On Tue, Jan 15, 2019 at 1:59 PM Lennart Poettering wrote: > Maybe use this instead: > >"count=fresh" → this is the first dnf invocation on a fresh install >"count=monthly" → this is used the first time in every 29.53 day > cycle, except if this is a fresh install > (i.e. count=fresh is sent instead) >"count=weekly" → this is used the first time in every 7 day cycle, > except if this is a fresh install or also the > first time in the 29.53 day cycle (i.e. only if > neither count=fresh nor count=monthly are sent) I suggest to add one more value: "count=upgraded" - this is the first invocation after system was upgraded to the new Fedora version Marek -- Marek Blaha ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: libcrypt.so.1 (compatibility library for POSIX): Let encrypt, encrypt_r, setkey, setkey_r, and fcrypt return ENOSYS instead of performing any real operation
Am Dienstag, den 15.01.2019, 15:20 +0100 schrieb Florian Weimer:
> * Simo Sorce:
>
> > > Maybe the stub implementation should just overwrite the argument
> > > with
> > > zeros.
> >
> > I wouldn't overwrite with zeros because then it is clear the
> > encryption
> > failed and if it is used in non-orthodox ways could give an attacker
> > a
> > way to exploit the zeroing.
> >
> > (for example if someone uses it to encrypt a password, instead of
> > hashing it and then compare to some stored value, then zeroing might
> > be
> > a bad choice as all invocations will always return the same value
> > and
> > would always compare "right")
>
> That's a fair point. Overwriting with random data seems better.
> (There's precedent for doing that on decryption failures, too.)
>
> Thanks,
> Florian
Thanks for the thoughts and a easy solution, guys! I've updated the
description and documentation of the proposal accordingly:
> The encrypt{,_r} function will - for security reasons - additionally
> overwrite the data-block argument with random data.
Björn
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Release rpkg-1.57
Hi all, a new version rpkg-1.57 is released. This is mostly a bugfix update with improvements for building modules and flatpaks - Set configuration in case of "clone --branches" as well - Send source mtime to dist-git - Specify package manager for mock-config - Add contributing guide - Validate the module build optional argument when parsing the argument - Add config options to parse the base module (e.g. platform) stream from the dist-git branch and apply a buildrequire override - Add the ability to pass in buildrequire and require overrides on a module build - Raise an error if the module build command receives optional arguments that conflict - Add flatpak-build subcommand More specific changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.57.html Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.57-2.el6&builds=rpkg-1.57-2.el7&builds=rpkg-1.57-2.fc28&builds=rpkg-1.57-2.fc29 Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 rpkg is available from PyPI. Regards Ondrej Nosek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Server Side Public License (SSPL) v1
After review, Fedora has determined that the Server Side Public License v1 (SSPL) is not a Free Software License. It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users. Additionally, it seems clear that the intent of the license author is to cause Fear, Uncertainty, and Doubt towards commercial users of software under that license. To consider the SSPL to be "Free" or "Open Source" causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk. It is also worth nothing that while there is a draft for a "v2" of the SSPL: A) It is not final. B) It is not in use anywhere at this time (as far as we know). C) The intent of the v2 draft text is not changed from the v1 license currently in use. We have updated our "Bad License" list to include SSPLv1. No software under that license may be included in Fedora (including EPEL and COPRs). Thanks, Tom Callaway Fedora Legal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190115.n.0 changes
OLD: Fedora-Rawhide-20190114.n.0 NEW: Fedora-Rawhide-20190115.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 4 Dropped packages:28 Upgraded packages: 271 Downgraded packages: 1 Size of added packages: 9.63 MiB Size of dropped packages:22.57 MiB Size of upgraded packages: 6.67 GiB Size of downgraded packages: 8.51 MiB Size change of upgraded packages: 121.29 MiB Size change of downgraded packages: -43.82 KiB = ADDED IMAGES = Image: AtomicHost dvd-ostree aarch64 Path: AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-Rawhide-20190115.n.0.iso Image: AtomicHost dvd-ostree ppc64le Path: AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-Rawhide-20190115.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: python-dictdiffer-0.7.1-2.fc30 Summary: Dictdiffer is a module that helps you to diff and patch dictionaries RPMs:python-dictdiffer-doc python3-dictdiffer Size:4.71 MiB Package: python-nistats-0.0.1-0.1b0.fc30 Summary: Modeling and Statistical analysis of fMRI data in Python RPMs:python-nistats-doc python3-nistats Size:178.92 KiB Package: python-string_utils-0.6.0-4.fc30 Summary: A python module containing utility functions for strings RPMs:python-string_utils-doc python3-string_utils Size:4.69 MiB Package: rust-env_logger0.5-0.5.13-3.fc30 Summary: Logging implementation for `log` which is configured via environment variable RPMs:rust-env_logger0.5+default-devel rust-env_logger0.5+regex-devel rust-env_logger0.5-devel Size:54.66 KiB = DROPPED PACKAGES = Package: golang-github-AudriusButkevicius-kcp-go-0-0.8.20171227git5d7d1a8.fc30 Summary: Full-featured reliable UDP communication library RPMs:golang-github-AudriusButkevicius-kcp-go-devel Size:39.27 KiB Package: golang-github-AudriusButkevicius-pfilter-0.0.3-6.fc30 Summary: Simple Packet Filtering package written in Go RPMs:golang-github-AudriusButkevicius-pfilter-devel Size:12.29 KiB Package: golang-github-calmh-luhn-2.0.0-6.fc30 Summary: Luhn-mod-N implementation in Go RPMs:golang-github-calmh-luhn-devel Size:10.95 KiB Package: golang-github-ccding-go-stun-0.1.0-11.20180831gitbe486d1.fc30 Summary: STUN client (RFC 3489 and RFC 5389) implementation in Go RPMs:golang-github-ccding-go-stun-devel Size:24.89 KiB Package: golang-github-cznic-b-0-0.9.20180831git35e9bbe.fc30 Summary: B+ Tree implementation in Go RPMs:golang-github-cznic-b-devel Size:20.84 KiB Package: golang-github-cznic-fileutil-0-0.11.20180831git6a051e7.fc30 Summary: File utility functions for Go RPMs:golang-github-cznic-fileutil-devel Size:232.79 KiB Package: golang-github-cznic-golex-0-0.9.20180831git4ab7c5e.fc30 Summary: Lex/Flex-like utility written in Go RPMs:golang-github-cznic-golex golang-github-cznic-golex-devel Size:4.97 MiB Package: golang-github-cznic-internal-1.0.0-9.20180831git4747030.fc30 Summary: Shared dependencies for other cznic Go libraries RPMs:golang-github-cznic-internal-devel Size:19.95 KiB Package: golang-github-cznic-lex-0-0.8.20180831git68050f5.fc30 Summary: Support for (f)lex-like tool on .l source files RPMs:golang-github-cznic-lex-devel Size:26.14 KiB Package: golang-github-cznic-lexer-0-0.8.20180831git52ae786.fc30 Summary: Run time generator of action less scanners written in Go RPMs:golang-github-cznic-lexer-devel Size:26.65 KiB Package: golang-github-cznic-lldb-1.1.0-8.fc30 Summary: Low-level database engine implementation in Go RPMs:golang-github-cznic-lldb-devel Size:69.84 KiB Package: golang-github-cznic-mathutil-0-0.15.20180831gitca4c9f2.fc30 Summary: Supplemental utilities for Go's rand and math packages RPMs:golang-github-cznic-mathutil-devel Size:91.54 KiB Package: golang-github-cznic-ql-1.2.0-4.fc30 Summary: Embedded SQL database written in Go RPMs:golang-github-cznic-ql golang-github-cznic-ql-devel Size:14.87 MiB Package: golang-github-cznic-sortutil-0-0.8.20180831git4c73428.fc30 Summary: Supplemental utilities for Go's sort package RPMs:golang-github-cznic-sortutil-devel Size:13.67 KiB Package: golang-github-cznic-strutil-0-0.9.20180831git529a34b.fc30 Summary: Supplemental utilities for Go's strings package RPMs:golang-github-cznic-strutil-devel Size:18.02 KiB Package: golang-github-cznic-zappy-0-0.8.20180831git2533cb5.fc30 Summary: Block-based compression format implementation in Go RPMs:golang-github-cznic-zappy-devel Size:20.25 KiB Package: golang-github-edsrzf-mmap-go-0-0.6.20170318git0bce6a6.fc30 Summary: Portable mmap package for Go RPMs:golang-github-edsrzf-mmap-go-devel Size:13.69 KiB Package: golang-github-klauspost-reedsolomon-1.6-6.20180704git925cb01.fc30 Summary: Reed-Solomon Erasure Coding in Go RPMs:golang-github-klauspost-reedsolomon-devel Size:782.27 KiB Package: golang-github-remyoudompheng-bigfft-0-0.8.git52369
Re: rpmbuild: File listed twice (but only build-ids)
Ooooaaa... So this has been around since at least 2017 and there's no fix? Is there an option to make it a warning again instead of an error? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora's purpose [was Re: Editions vs. Spins...] DNF UUID)
On Mon, Jan 14, 2019 at 07:58:43PM -0500, John Harris wrote: > > Merging Core and Extras into one thing was absolutely the > > right thing to do for the project, but not having a unique name for the > > resulting OS was a mistake and leads to this. Ah well. > In your opinion, is the purpose of the Fedora Project something other than > the creation and maintenance of the distribution known as Fedora? It has always been broader than that. Way back in history, the project was created by the merger of the (short-lived) "Red Hat Linux Project", which had a narrow distro-producing mission, and fedora.us, which had the goal of publishing what it described as "third-party software" _on top of_ that distribution. When these projects merged, they nominally took on the Red Hat Linux Project mission, but in practice, the effort remained wider — for example, the Fedora Legacy effort to provide security updates for non-Fedora Red Hat Linux 8 and 9. Take a look at the "Objectives of Fedora" list from back in 2008 https://fedoraproject.org/w/index.php?title=Objectives&oldid=2124 ... actually this is even older but we lost wiki history from before that. Building a distro is *one* of the objectives, but they're not really all *just* about that. This was reflected in the 2010 mission statement "to lead the advancement of free and open source software and content as a collaborative community." At that time, the above page was expanded (see https://fedoraproject.org/w/index.php?title=Objectives&oldid=157737) and included these top level things: * "Creating a Free (as in Freedom) distribution" * "Building open source software communities" * "Developing the science and practice of building communities" When the Council sat down to review this two years ago, we felt like in some ways the ambition there exceeded our practical *actual* abilities, and we chose to dial back the scope a bit and to focus on platform building. (That resulted in the current mission statement: "Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.") That platform, still, is broader than what is commonly understood as "the distribution known as Fedora". Notably, it includes EPEL, which, by the numbers, is used on many more systems than the Fedora OS distribution itself. (In many ways, I think EPEL is the natural successor to the fedora.us part of our heritage.) It also includes CoreOS, and Silverblue, and the IoT thing (which needs a catchy name). These are built from the same bits but are in many ways different from our traditional distribution. In the future, we should also be open to building and including open source software in non-RPM formats and considering that all under the Fedora umbrella as well. If we scoped our mission to just maintaining the distro as it exists today, we might not feel like that's even possible. We shouldn't limit ourselves in that way. Likewise, Kevin mentioned earlier in this thread the view that "the Fedora user base is clearly desktop-centric". I don't think that's actually completely true (see EPEL and CoreOS, but also the lots of people who came into the project from a server/sysadmin background). But even if we take it as true, that view leads inevitably to an overall narrowing. It's only a small step to "the Fedora user base is clearly GNOME-centric" and so on down. Now, we *could* take the strategic direction that it'd be better to cut all that stuff away and really focus on making that desktop GNOME OS _only_. We could probably do that very successfully, even. But to me that doesn't feel right for the project's heritage. We've decided to go the other direction. Rather than picking one narrow thing and saying "this OS offering *is* Fedora", we want to enable *lots* of different solutions and offerings under the Fedora Project umbrella. If an idea fits with our core values and you want to work on it in Fedora, *awesome*. So, although I disagree about Editions and the getfedora.org web site, I *do* want to see Fedora KDE Plasma Desktop, Fedora Cinnamon Desktop, Fedora Astronomy Lab, Fedora Jam, and all the rest get more promotion and support. That's totally the within the project's mission, and I totally support the teams behind those efforts. The Mindshare Committee and the Council can't promise *people* to do things, but we can allocate funds to help drive towards subproject goals. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Modularity] Working Group IRC meeting minutes (2019-01-15)
= #fedora-meeting-3: Weekly Meeting of the Modularity Working Group = Meeting started by nils at 15:00:00 UTC. Minutes: https://meetbot.fedoraproject.org/fedora-meeting-3/2019-01-15/modularity_wg.2019-01-15-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-3/2019-01-15/modularity_wg.2019-01-15-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-3/2019-01-15/modularity_wg.2019-01-15-15.00.log.html Meeting summary --- * Roll Call (nils, 15:00:01) * Agenda (nils, 15:01:41) * #112 Discussion: Module lifecycles (nils, 15:01:51) * #115 Discussion: Stream branch ownership for packages & modules (nils, 15:01:51) * #119 Modularity WG Charter (contd.) (nils, 15:01:51) * #123 & #124 Service Levels, EOLs (nils, 15:01:51) * #112 Discussion: Module lifecycles (nils, 15:03:25) * LINK: https://pagure.io/modularity/issue/112 (nils, 15:03:25) * LINK: https://pagure.io/fesco/issue/2027 (nils, 15:03:25) * ongoing, asamalik in discussion with FESCo, postponed (nils, 15:05:31) * #115 Discussion: Stream branch ownership for packages & modules (nils, 15:05:42) * LINK: https://pagure.io/modularity/issue/115 (nils, 15:05:43) * LINK: https://pagure.io/fesco/issue/2028 (nils, 15:05:46) * asamalik will update the proposal to include explicit package branch ownership and will review that with FESCo again (asamalik, 15:10:03) * #119 Modularity WG Charter (contd.) (nils, 15:10:52) * LINK: https://pagure.io/modularity/issue/119 (nils, 15:10:53) * AGREED: with amendment (+4, 0, -0) (nils, 15:22:20) * #123 & #124 Service Levels, EOLs (nils, 15:24:10) * LINK: https://pagure.io/modularity/issue/123 (nils, 15:24:11) * LINK: https://pagure.io/modularity/issue/124 (nils, 15:24:11) * LINK: https://pagure.io/releng/issue/8057 Unblock/reactivate the 9.6 stream branch of the postgresql module (nils, 15:27:21) * ACTION: asamalik updates docs and coordinates the necessary tooling changes (nils, 15:53:41) Meeting ended at 15:55:35 UTC. Action Items * asamalik updates docs and coordinates the necessary tooling changes Action Items, by person --- * asamalik * asamalik updates docs and coordinates the necessary tooling changes * **UNASSIGNED** * (none) People Present (lines said) --- * nils (71) * contyk (25) * asamalik (23) * zodbot (14) * langdon (5) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rpmbuild: File listed twice (but only build-ids)
On Tue, 2019-01-15 at 10:40 -0600, Richard Shaw wrote: > Ooooaaa... > > So this has been around since at least 2017 and there's no fix? Much longer than that. At least since 2012, probably earlier. %exclude is discouraged, which is why it doesn't seem to have higher priority. See also: https://bugzilla.redhat.com/show_bug.cgi?id=878863 (Although that bug is a little confusing since it seems to mix up two issues with exclude files and build-id symlinks.) It is a variant of: https://github.com/rpm-software-management/rpm/issues/284 The fix for that excludes debug files for files which were excluded in the non-debug package. A similar fix should be done for generating the build-ids only for binaries not in the pkg->fileExcludeList. Currently the generateBuildIDs () function in build/files.c only gets the full package file list. It probably should also get the fileExcludeList and only generate the build-id links for files not on that list. The interaction between the different package lists is a little confusing though. It is probably best to ask for guidance on the upstream mailinglist rpm-ma...@lists.rpm.org (CCed). > Is there an option to make it a warning again instead of an error? I don't think without disabling build-ids completely. Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The "see-also" field in bugzilla
On Tue, 2019-01-15 at 13:15 +0100, Emmanuel Seyman wrote: > * Jan Synacek [15/01/2019 12:45] : > > Unless I'm missing something, you have to use "External Trackers" on both > > sides. With "SeeAlso", you specified it in one bugzilla and it > > automatically showed in the referenced one. > > This only works if both bugs are in the same instance. There's never been > inter-bugzilla-instances communication (thoough I've threatened the bugzilla > deps to add this). But many of us were using it precisely *for* this. The removal seems to have been based on the assumption that 'See also' was *only* being used for referring to external bugs, but this was not in fact the case at all. I used it exclusively for referring to other bugs within BRC which were *relevant*, but not *duplicates* or *dependencies*. "External Trackers" does not cover this at all. To my mind they were quite different features. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The "see-also" field in bugzilla
On Tue, 2019-01-15 at 09:25 -0800, Adam Williamson wrote: > On Tue, 2019-01-15 at 13:15 +0100, Emmanuel Seyman wrote: > > * Jan Synacek [15/01/2019 12:45] : > > > Unless I'm missing something, you have to use "External Trackers" on both > > > sides. With "SeeAlso", you specified it in one bugzilla and it > > > automatically showed in the referenced one. > > > > This only works if both bugs are in the same instance. There's never been > > inter-bugzilla-instances communication (thoough I've threatened the bugzilla > > deps to add this). > > But many of us were using it precisely *for* this. The removal seems to > have been based on the assumption that 'See also' was *only* being used > for referring to external bugs, but this was not in fact the case at > all. I used it exclusively for referring to other bugs within BRC which > were *relevant*, but not *duplicates* or *dependencies*. "External > Trackers" does not cover this at all. To my mind they were quite > different features. Exactly! I don't think I've wver seen see-also pointing to an external bug, it was always used to link related bugs in the Red Hat Bugzilla instance & that's how I always used it as well. > -- > 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Re: Fedora 30 Rawhide 20190114.n.0 nightly compose nominated for testing
On Mon, 2019-01-14 at 10:22 +, rawh...@fedoraproject.org wrote: > Announcing the creation of a new nightly release validation test event > for Fedora 30 Rawhide 20190114.n.0. Please help run some tests for this > nightly compose if you have time. For more information on nightly > release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Test coverage information for the current release can be seen at: > https://www.happyassassin.net/testcase_stats/30 > > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190114.n.0_Summary > > The individual test result pages are: > > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190114.n.0_Installation > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190114.n.0_Base > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190114.n.0_Server > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190114.n.0_Cloud > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190114.n.0_Desktop > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190114.n.0_Security_Lab So, a couple of notes on this compose. It has two obvious major bugs. One: https://bugzilla.redhat.com/show_bug.cgi?id=1663040 the manifestation of that in 20190114.n.0 is that many services fail to start on live images, which prevents at least the Workstation live from booting at all. To work around this, boot the image with 'enforcing=0'. Secondly, interface elements like radio buttons and checkboxes in the installer don't display the actual checkmark or dot or whatever to indicate they are selected. This appears to be some sort of GNOME component mismatch, or something, because a new gtk3 build appeared just after the compose ran: https://koji.fedoraproject.org/koji/buildinfo?buildID=1179328 with that gtk3, this works fine - so it works fine in today's compose, 20190115.n.0. We're currently working on fixes for #1663040; if we can get that sorted out for tomorrow's compose, I'll probably force a new validation event to be created. Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphan winetricks
Hi there, I tend to orphan winetricks. Reasons noted in the usability bug [¹] with known dependency issues, reported from an user. Besides, there are better alternatives available for my personal needs. Please feel free to request ownership for this package if you think it's still useful in Fedora. Regards, Raphael [¹] https://bugzilla.redhat.com/show_bug.cgi?id=1626632 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora updates-20190116.0 compose check report
No missing expected images. Failed openQA tests: 2/2 (x86_64) Old failures (same test failed in testing-20190115.0): ID: 345336 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/345336 ID: 345337 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/345337 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora testing-20190116.0 compose check report
No missing expected images. Failed openQA tests: 2/2 (x86_64) ID: 345338 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/345338 ID: 345339 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/345339 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 System-Wide Change Proposal: Fully remove deprecated and unsafe functions from libcrypt
On Wed, Jan 02, 2019 at 04:14:59PM -0500, Ben Cotton wrote: > == Detailed Description == > At the time those interfaces have been implemented they internally > relied on using the DES encryption algorithm, that today is widely > considered unsecure and insufficient for applications which require > sane data encryption. There are various recommendations new written > code should not use them anymore. DES has been proven insecure against brute force for over two decades. > Some users may use software from third-parties that may still use > those interfaces silently and possibly sacrificing the security of the > user's sensitive data silently. > > For that reason those interfaces should genrally not be available by > default for existing third-party applications in Fedora anymore. > Fedora users should be aware whether they use applications that > utilize secure encryption algorithms or not. > > To accomplish this we are going to bump the shared object name of > libcrypt.so from 1 to 2 and remove all of the functions that are > considered unsafe. The maintain POSIX or otherwise compatibility, we > keep providing a compatibility library (libcrypt.so.1) in a separated > package, that can be installed by the user. But this happens all the time with other libraries, so I doubt an uninformed user will understand you did it on purpose unless you do something more. How do we plan to describe the package in the summary/description? And if they don't look at that, what clue will the user get that they might want to re-think the install of the compat package? Maybe this package should be named "libxcrypt-compat-insecure-read-description-before-install"? Or at least *something* that screams "wait, maybe I should look into this more, this isn't standard operating procedure..."? > == User Experience == > No user-visible impacts, but maybe the need for manually installing > the libxcrypt-compat package for some third-party applications. This seems a little problematic given the motivation behind this change. > == Documentation == > The version of the libxcrypt package included with Fedora 30 now ships > the libcrypt.so2 library and does not provide the legacy API functions > that have been provided by glibc's libcrypt.so.1. The removed > functions by name are encrypt, encrypt_r, setkey, setkey_r, and > fcrypt. > > If you are using a third-party application that links against those > functions, or that is linked against glibc's libcrypt, you may need to > install the libxcrypt-compat package manually. > > All existing binary executables linked against glibc's libcrypt should > work unmodified with the libcrypt.so.1 library supplied by the > libxcrypt-compat package. And I object to nothing in this section informing the user that "those interfaces ... possibly sacrific[e] the security of the user's sensitive data silently." Especially since it appears that this will the wording that goes into the release notes. > == Release Notes == > See the paragraph about documentation above. See objections above. -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora testing-20190116.0 compose check report
On Wed, 2019-01-16 at 02:34 +, Fedora compose checker wrote: > No missing expected images. > > Failed openQA tests: 2/2 (x86_64) > > ID: 345338Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi > URL: https://openqa.fedoraproject.org/tests/345338 > ID: 345339Test: x86_64 AtomicHost-dvd_ostree-iso install_default > URL: https://openqa.fedoraproject.org/tests/345339 Note - these mails should really go to the Atomic list (rather than test@ and devel@), but I need to update some things to make this happen (it worked when we had 'Fedora-Atomic' composes, but now those went away and we have these updates composes instead, it doesn't). It seems the Atomic installer images from the nightly 'updates' and 'updates-testing' composes for F29 started failing as of 20190115.n.0 and still failed in 20190116.n.0. Failure looks like: https://openqa.fedoraproject.org/tests/345339#step/_do_install_and_reboot/4 not sure what the cause is. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphan winetricks
On Wed, Jan 16, 2019 at 2:35 AM Raphael Groner wrote: > Hi there, > > I tend to orphan winetricks. Reasons noted in the usability bug [¹] with > known dependency issues, reported from an user. > Besides, there are better alternatives available for my personal needs. > Please feel free to request ownership for this package if you think it's > still useful in Fedora. > > Regards, Raphael > > [¹] https://bugzilla.redhat.com/show_bug.cgi?id=1626632 > Doesn’t seem like there are any takers yet, so I created a request. -- Ernestas Kulik Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
