Automatic close of bugs for retired packages?
by Pavel Raiskup
I today tried to mimic something that random Fedora user can do, and I
submitted bug against one of our long-time retired components. I haven't
been warned at all that the package is dead.
As user, it is easy to pick a wrong component when filling a bug - but the
problem with orphaned/retired packages is that nobody listens there
usually. Only 'Orphan Owner <extras-orphan(a)fedoraproject.org>'.
Should such reports be kindly closed automatically by some bot, so user
can reopen against different component? Or should we drop the component
from bugzilla?
Pavel
4 years, 1 month
Re: Non-responsive maintainer: pocock
by Neal Gompa
On Tue, Mar 3, 2020 at 4:10 AM Daniel Pocock <daniel(a)pocock.com.au> wrote:
>
>
>
> On 28/02/2020 10:00, Ankur Sinha wrote:
> > On Thu, Feb 27, 2020 17:07:21 -0500, Dakota Williams via devel wrote:
> >> On 2/26/20 6:59 PM, Daniel Pocock wrote:
> >> <snip>
> >>>>
> >>>> Would you like help? I'd be willing to be a co-maintainer to make the
> >>>> branch.
> >>>
> >>> Yes, I would welcome help with these packages
> >>>
> >>> But there is also an increasing problem of making decisions about trust
> >>>
> >>> In the case of developers who I haven't met or worked with, I don't
> >>> really know how to proceed
> >>>
> >>> I've seen several extraordinary examples of developers doing things that
> >>> undermine my confidence in them over the last couple of years. The
> >>> fighting within GNU and FSF right now is the latest iteration of that.
> >>>
> >>> Now, whenever I receive a request from somebody I don't know, there is
> >>> an extra effort for me to decide how to proceed.
> >>>
> >>> Maybe I can simply resign from maintaining the asio package and then opt
> >>> out of the process of choosing a new maintainer.
> >>>
> >>> Please don't take this personally: it is a reflection of the overall
> >>> state of free software communities today.
> >>>
> >> I don't know about the situation with the GNU project and the FSF, but if
> >> there's something you'd like me to do to prove trust, I could do it.
> >
> > I'd like to add that by default we trust each other, in the spirit of
> > being excellent to each other. In this particular case,
>
> Why, then, have my replies to this thread never appeared in the mailing
> list then, only to the people on CC?
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
I do not know why. I have filed an issue with infrastructure to find
out: https://pagure.io/fedora-infrastructure/issue/8713
> My own statement wasn't directed at any particular maintainer and
> doesn't imply that I am ungrateful for any offers of help. I am very
> grateful for those people, including Dakota, who reached out in a
> positive way.
>
> Trust is not a constant thing, it can change over time. The wider
> atmosphere and the disappearance of messages from mailing lists
> contributes to lower confidence.
>
> Unfortunately, I now see several emails every week (not necessarily from
> the Fedora mailing lists) that cause suspicion and concern. I then feel
> a need to look at every other interaction more carefully.
>
> When I mentioned the death of my father in a blog recently, my blog was
> removed from Planet Fedora. Now it seems my emails go to a moderator
> who doesn't have the time to keep up with all those censorship duties.
> I find this behaviour incredibly insulting and degrading, I suspect
> anybody in my position would feel the same way.
>
I'm sorry about that. I don't know what happened there either.
> > co-maintainership shares responsibility but does not hand it over
> > completely (the handing-over bit can be done at a later stage, if
> > necessary). Every change/commit/message is public, so there are plenty
> > of opportunities to catch any errors.
> >
> > Given that we do not often meet our Fedora colleagues in person, it is
> > not viable to expect members of the community to prove trustworthiness
> > through personal relationships. We assume the best in each other, and if
> > things do get hairy, we have open community channels, processes, and
> > overseeing bodies through which changes can be emended.
>
> My email was not a request for Dakota or anybody else to prove
> trustworthiness, it was only a reflection of my own perception of things
> going on in the wider free software community.
>
> But based on what you say, I'm happy to give access to Dakota and I'd
> also like to know if anybody else can help with the reSIProcate
> packages. There is a new release in the pipeline and if somebody wants
> to get involved, now is the time. We already made all the upstream
> fixes required for it to work with the latest dependencies on Fedora.
>
Thanks for granting Dakota maintainer privileges for asio! :)
I may be able to spare some cycles to help with reSIProcate (after I
get out of my mountain of FTBFS issues...). I'm sure other folks here
could help as well. :)
--
真実はいつも一つ！/ Always, there's only one truth!
4 years, 1 month
updates-testing and koji
by Iñaki Ucar
Hi all,
Quick question: if a new package A is in updates-testing, is it
available for koji to build another new package B that requires A? Or
do I need to wait until A reaches stable?
Regards,
Iñaki
4 years, 1 month
Filtering devel list e-mail
by Miro Hrončok
On 28. 02. 20 11:21, Radka Janekova wrote:
> Please excuse me going completely offtopic here - for some reason I'm getting
> this thread addressed directly to me. If someone's adding me as bcc please
> don't, I have nothing to do with this.
Hey Radka.
Do you filter devel list via the "List-Id:" or "To:" header? Is it possible that
you get this to your inbox because the devel list was cc'ed, not you?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 1 month
__pycache__ in /usr/share
by Steve Grubb
Hello,
We are working on Application Whitelisting. For this to work, we need to have
a list of things that we trust. At the moment, that list is well over 400k on
a desktop install. But we really need to get that smaller.
According to the Linux FHS standard, /usr/share is supposed to only contain
data. Executables have other places to live. If we can assume that there is
only data in /usr/share, then we can remove about 330k of the items from our
trust database.
However, I'm finding that on a typical system, there are about 20 packages
that place python byte code in /usr/share. Is it possible to move those
python modules to another location? The packaging guidelines imply, but not
require, that they belong over in /usr/lib64/ somewhere.
Reducing the trust database is important to the application whitelisting
project. Does making /usr/share/ data only sound feasible?
Thanks,
-Steve
4 years, 1 month
Re: Non-responsive maintainer: pocock
by Radka Janekova
On Fri, Feb 28, 2020 at 1:39 PM Daniel Pocock <daniel(a)pocock.com.au> wrote:
>
> On 28/02/2020 11:21, Radka Janekova wrote:
> > Please excuse me going completely offtopic here - for some reason I'm
> > getting this thread addressed directly to me. If someone's adding me as
> > bcc please don't, I have nothing to do with this.
>
>
> A lot of people are using CC or BCC, as described in the Fellowship
> blog[1], due to censorship problems and culture wars. For example, some
> messages in this thread don't appear at all in the list archives[2]. Why?
>
Honestly I do not care what so ever. Nobody should bother people with their
emails - especially since most of us take a lot of care to not miss very
important work emails among the hundreds, if not even thousands of emails
that we receive every day (I personally received 250 emails only today, and
it's just the beginning of the NA timezone. By the time I wake up tomorrow
it sure will be 400 or more.) Within this amount of emails even with
complex filters in place, a responsible engineer will read through the
subject lines of every email at least in the relevant mailing lists. Email
like this one, with some sneaky bcc being added every 4th email so that the
thread keeps reappearing even after it's dismissed, gets ignored by that
complex system of filters, because the filter doesn't actually see why did
I receive this email. As such it lands in my HIGH PRIORITY inbox. This
freaks me out. Please stop.
If you have issues with sending emails to anything, contact administrators.
This is not a solution. If anything you will get your own email flagged as
spam by large number of people, which will lead exactly to what you're
trying to prevent/circumvent, just worse.
> If you see something like that, please share the full headers so we can
> all see how the message reached you, otherwise it is ambiguous.
>
> Regards,
>
> Daniel
>
>
> 1. https://fsfellowship.eu/freedom-and-censorship-on-mailing-lists/
> 2.
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
>
4 years, 1 month
GNOME 3.35.92 megaupdate
by Kalev Lember
Hi all,
I am putting together a megaupdate for GNOME 3.35.92. If you are helping
with builds, please wait until we have the f32-gnome side tag (requested
in https://pagure.io/releng/issue/9292) and then do the F32 builds with
'fedpkg build --target f32-gnome'. I'll collect all the builds tagged
with f32-gnome for the megaupdate and submit them to Bodhi all together.
Same drill next week for 3.36.0 release.
Thanks!
--
Kalev
4 years, 1 month
Fedora-32-20200303.n.0 compose check report
by Fedora compose checker
No missing expected images.
Failed openQA tests: 24/171 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-32-20200302.n.0):
ID: 531292 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/531292
ID: 531317 Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/531317
Old failures (same test failed in Fedora-32-20200302.n.0):
ID: 531249 Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/531249
ID: 531251 Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/531251
ID: 531275 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/531275
ID: 531282 Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/531282
ID: 531299 Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/531299
ID: 531306 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/531306
ID: 531315 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/531315
ID: 531329 Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/531329
ID: 531332 Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/531332
ID: 531334 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/531334
ID: 531335 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/531335
ID: 531344 Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/531344
ID: 531345 Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/531345
ID: 531352 Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/531352
ID: 531355 Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/531355
ID: 531357 Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/531357
ID: 531360 Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/531360
ID: 531373 Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/531373
ID: 531385 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/531385
ID: 531392 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/531392
ID: 531393 Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/531393
ID: 531398 Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/531398
ID: 531399 Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/531399
Soft failed openQA tests: 16/171 (x86_64)
(Tests completed, but using a workaround for a known bug)
New soft failures (same test not soft failed in Fedora-32-20200302.n.0):
ID: 531302 Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/531302
Old soft failures (same test soft failed in Fedora-32-20200302.n.0):
ID: 531227 Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/531227
ID: 531228 Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/531228
ID: 531232 Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/531232
ID: 531235 Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/531235
ID: 531236 Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/531236
ID: 531256 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/531256
ID: 531285 Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/531285
ID: 531287 Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/531287
ID: 531319 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/531319
ID: 531328 Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/531328
ID: 531346 Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/531346
ID: 531381 Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/531381
ID: 531384 Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/531384
ID: 531391 Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/531391
ID: 531453 Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/531453
Passed openQA tests: 129/171 (x86_64)
New passes (same test not passed in Fedora-32-20200302.n.0):
ID: 531253 Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/531253
ID: 531265 Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/531265
ID: 531330 Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/531330
Skipped non-gating openQA tests: 3 of 173
Installed system changes in test x86_64 Server-boot-iso install_default@uefi:
1 services(s) added since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-6DA9\x2dA083.service
1 services(s) removed since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-02B4\x2d3D95.service
Previous test data: https://openqa.fedoraproject.org/tests/530577#downloads
Current test data: https://openqa.fedoraproject.org/tests/531228#downloads
Installed system changes in test x86_64 Server-dvd-iso install_default@uefi:
1 services(s) added since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-75AA\x2d251E.service
1 services(s) removed since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-0C7E\x2dA8D9.service
Previous test data: https://openqa.fedoraproject.org/tests/530581#downloads
Current test data: https://openqa.fedoraproject.org/tests/531232#downloads
Installed system changes in test x86_64 Everything-boot-iso install_default@uefi:
2 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-0578f10c\x2df444\x2d4b83\x2da942\x2d3260538ae949.service, systemd-fsck(a)dev-disk-by\x2duuid-6F13\x2dEB20.service
2 services(s) removed since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-033F\x2d38CE.service, systemd-fsck@dev-disk-by\x2duuid-8eb92994\x2dad4c\x2d414e\x2d8a99\x2d31712d3100fe.service
Previous test data: https://openqa.fedoraproject.org/tests/530618#downloads
Current test data: https://openqa.fedoraproject.org/tests/531269#downloads
Installed system changes in test x86_64 Everything-boot-iso install_default:
1 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-88f77bd2\x2d3551\x2d4389\x2db9c2\x2d8483d0296e1b.service
1 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-d2394341\x2d0ed9\x2d427f\x2db7fc\x2d20d571d00102.service
Previous test data: https://openqa.fedoraproject.org/tests/530619#downloads
Current test data: https://openqa.fedoraproject.org/tests/531270#downloads
Installed system changes in test x86_64 Workstation-live-iso install_default@uefi:
2 services(s) added since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-6B11\x2d28FF.service, systemd-fsck@dev-disk-by\x2duuid-8a49d3b5\x2d3366\x2d449e\x2dbecf\x2dfd7db761aeaa.service
2 services(s) removed since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-0485\x2d0B3F.service, systemd-fsck@dev-disk-by\x2duuid-13437a59\x2d8bd0\x2d490e\x2da88d\x2d18d9b690b590.service
System load changed from 0.40 to 0.60
Previous test data: https://openqa.fedoraproject.org/tests/530621#downloads
Current test data: https://openqa.fedoraproject.org/tests/531272#downloads
Installed system changes in test x86_64 Workstation-live-iso install_default_upload:
1 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-bcd4d4ae\x2d2aaa\x2d4cd8\x2d895f\x2d46faa821d202.service
1 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-7ecc0521\x2de8da\x2d4177\x2daf6f\x2d235b3f818a32.service
System load changed from 0.89 to 1.13
Average CPU usage changed from 13.4 to 31.36666667
Previous test data: https://openqa.fedoraproject.org/tests/530622#downloads
Current test data: https://openqa.fedoraproject.org/tests/531273#downloads
Installed system changes in test x86_64 KDE-live-iso install_default@uefi:
2 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-65a574e3\x2db9fa\x2d43f3\x2db8d0\x2d4cb0257123bd.service, systemd-fsck(a)dev-disk-by\x2duuid-7D08\x2d5A06.service
2 services(s) removed since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-1982\x2d1EEB.service, systemd-fsck@dev-disk-by\x2duuid-502847b9\x2d21b4\x2d452e\x2d8b9a\x2dd9a3efe008d3.service
System load changed from 1.21 to 1.10
Previous test data: https://openqa.fedoraproject.org/tests/530639#downloads
Current test data: https://openqa.fedoraproject.org/tests/531290#downloads
Installed system changes in test x86_64 KDE-live-iso install_default_upload:
Mount /run/user/0 appeared since previous compose
Used mem changed from 906 MiB to 718 MiB
1 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-6ca184ce\x2daacf\x2d46cc\x2d89cd\x2d95522e0a639d.service
1 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-0b794155\x2dec81\x2d4f25\x2db765\x2d291c104fd3f4.service
System load changed from 2.00 to 1.17
Previous test data: https://openqa.fedoraproject.org/tests/530640#downloads
Current test data: https://openqa.fedoraproject.org/tests/531291#downloads
Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi:
Used swap changed from 4 MiB to 5 MiB
2 services(s) added since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-598E\x2d1635.service, systemd-fsck@dev-disk-by\x2duuid-f2936f13\x2dd18a\x2d4aca\x2db80f\x2d480f570df520.service
2 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-8336430d\x2d1147\x2d4400\x2d943b\x2d1bc3d4c23004.service, systemd-fsck(a)dev-disk-by\x2duuid-E269\x2dF826.service
System load changed from 0.95 to 0.61
Previous test data: https://openqa.fedoraproject.org/tests/530657#downloads
Current test data: https://openqa.fedoraproject.org/tests/531308#downloads
Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload:
Used swap changed from 9 MiB to 2 MiB
1 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-2aae5a83\x2de4bd\x2d4e56\x2d82f3\x2db66533c14598.service
1 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-294990ba\x2d8d4e\x2d4b5d\x2d915a\x2d5bb9336f6298.service
Previous test data: https://openqa.fedoraproject.org/tests/530658#downloads
Current test data: https://openqa.fedoraproject.org/tests/531309#downloads
Installed system changes in test x86_64 universal install_package_set_kde:
Mount /run/user/0 appeared since previous compose
Used mem changed from 942 MiB to 778 MiB
1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service
1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service
System load changed from 1.21 to 1.36
Previous test data: https://openqa.fedoraproject.org/tests/530726#downloads
Current test data: https://openqa.fedoraproject.org/tests/531377#downloads
x86_64 Everything-boot-iso memory_check@uefi peak memory: 1143MiB (95% of previous compose peak)
x86_64 Everything-boot-iso memory_check peak memory: 1119MiB (94% of previous compose peak)
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
4 years, 1 month
