F24 - Edge scroll doesn't work anymore and two finger scroll always stay enabled
Hello, Edge scroll doesn't work anymore in Gnome/Mutter 3.20 (Fedora 24) and two finger scroll always stay enabled. I first thought that it was a libinput bug but Peter Hutterer, the libinput dev, showed me that my problem is due to a Mutter bug. https://bugs.freedesktop.org/show_bug.cgi?id=97090 It seem that the bug is already fixed in Mutter but hadn't been backported for now. https://bugzilla.gnome.org/show_bug.cgi?id=769276#c18 It will be great if the fix could be backported because edge scroll is, for a lot of people, an important part of user experience with a laptop and right now it's not available for Gnome 3.20 users. I opened an issue on Fedora and Gnome bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1364545 https://bugzilla.gnome.org/show_bug.cgi?id=769551 Thanks ! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Ntfs-3g - Files treated as executable
Hello, I'm on Fedora 24 and the files in my external USB HDD (NTFS) are always treated as executable. I thought it was a Nautilus bug but the Nautilus devs says it's an ntfs-3g problem (config ?) after I provided some gvfs-info and stat data as you can see in the bug report for Nautilus and in the one I open against ntfs-3g. https://bugzilla.gnome.org/show_bug.cgi?id=769181 https://bugzilla.redhat.com/show_bug.cgi?id=1363726 Is this a config problem that can "fixed" on ntfs-3g side ? Thanks ! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Disable ipv6 doesn't work
Hello, Disabling ipv6 in Gnome Control Center / Network / "My connection" doesn't work. ifconfig show that an ipv6 is still attributed and the problem I have with ipv6 enabled is still there (gone if I really disable ipv6). Thanks ! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Pending ACLs
On Sun, Aug 07, 2016 at 09:45:57AM +0530, Parag Nemade wrote: > Hi, > > On Sat, Aug 6, 2016 at 11:07 PM, wrote: > > Sometimes a maintainer doesn't want to approve ACLs for "reasons" but > > doesn't want to reject the request for various reasons including the > > requestor re-request of denied requests. > > > > 2) Sometime back I don't remember if I filed issue against pkgdb but I > discussed on IRC why not add some text entry box while requesting > ACLs. Not everyone knows everyother one here. Let the package owner > know why the ACL requestor need other package access. That will help > package owners to decide to approve or deny quickly. There can be some > people who want to have access/co-maintainer for some packages where > they really not needed to be. There is a ticket: https://github.com/fedora-infra/pkgdb2/issues/307 > 3) I am not sure but I think there is some automation for something in > pkgdb which automatically grants package access to requstor if package > owner do not take action. Correct me if I am wrong here. Not for ACLs, this is only when someone requests a new branch for a package that you have commit on while they do not. This way, if the current maintainers do not either approve or block the request, it will automatically be sent to rel-eng that will check if it is possible to add the branch and do it if it is. Pierre -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] Fedora 25 Branched 20160807.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 25 Branched 20160807.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 Notable package version changes: python-blivet - 20160803.n.0: python-blivet-2.1.1-2.fc25.src, 20160807.n.0: python-blivet-2.1.2-1.fc25.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/25 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_25_Branched_20160807.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160807.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160807.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160807.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160807.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160807.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160807.n.0_Security_Lab Thank you for testing! -- Mail generated by relval: https://www.happyassassin.net/relval/ ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Rawhide and F25 issues affecting QtWebEngine/QupZilla and Chromium
Hi, there are at least 3 issues in Rawhide (some or all of which also affect the Fedora 25 branch!) making both QupZilla (the main user of QtWebEngine) and Chromium fail to start up. One of them has no known workaround. And from my investigation, none of them appears to actually be IN QtWebEngine or Chromium code: 1. https://bugzilla.redhat.com/show_bug.cgi?id=1363914 [abrt] qupzilla: base::debug::BreakDebugger(): qupzilla killed by SIGABRT Apparent cause: selinux-policy Reason: because "setenforce 0" works around it F25 affected?: unknown Workaround: sudo setenforce 0 2. https://bugzilla.redhat.com/show_bug.cgi?id=1347436 fedora-import-state sets incorrect mode for /dev/shm when dracut places it in /run/initramfs/state (causes various things to break, inc. webkit and Boxes) Apparent cause: initscripts Reason: as per the bug report F25 affected?: yes (the bug was reported against F25, but it also happens in Rawhide) Workaround: sudo chmod a+w /dev/shm 3. https://bugzilla.redhat.com/show_bug.cgi?id=1364781 glibc 2.24 (2.23.90) breaks Chromium and QtWebEngine Received signal 4 ILL_ILLOPN 7f58262eac90 Apparent cause: glibc Reason: bisecting of OpenEmbedded changes by the OpenEmbedded folks: https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg82915.html F25 affected?: probably yes (it has the same glibc version) Workaround: none known In addition to these issues, there are also 4 crashes in the Nouveau graphics driver that can make QtWebEngine and probably Chromium crash: 1. https://bugzilla.redhat.com/show_bug.cgi?id=1349608 (pushbuf_kref, invoked by nv50_flush) 2. https://bugzilla.redhat.com/show_bug.cgi?id=1350275 (nouveau_fence_trigger_work) 3. https://bugzilla.redhat.com/show_bug.cgi?id=1362307 (nouveau_pushbuf_data) 4. https://bugzilla.redhat.com/show_bug.cgi?id=1364756 (nv50_screen_fence_update) I reassigned them to xorg-x11-drv-nouveau, but they have still not been looked at by a Nouveau maintainer. Considering that these issues break both the only up-to-date Qt browser (QupZilla) and the high-profile Chromium browser, I think they should have a really high priority. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 25-20160807.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Cloud_base raw-xz i386 Atomic raw-xz x86_64 Minimal raw-xz armhfp Failed openQA tests: 35/88 (x86_64), 6/17 (i386) ID: 27649 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27649 ID: 27651 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/27651 ID: 27652 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27652 ID: 27658 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27658 ID: 27659 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27659 ID: 27660 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/27660 ID: 27661 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27661 ID: 27662 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/27662 ID: 27663 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27663 ID: 27669 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/27669 ID: 27671 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27671 ID: 27674 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/27674 ID: 27677 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27677 ID: 27681 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/27681 ID: 27683 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/27683 ID: 27699 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/27699 ID: 27701 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/27701 ID: 27702 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/27702 ID: 27703 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/27703 ID: 27704 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/27704 ID: 27705 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/27705 ID: 27706 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/27706 ID: 27707 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/27707 ID: 27708 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/27708 ID: 27709 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/27709 ID: 27710 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/27710 ID: 27712 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/27712 ID: 27713 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/27713 ID: 27714 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/27714 ID: 27715 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/27715 ID: 27716 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/27716 ID: 27717 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/27717 ID: 27718 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/27718 ID: 27719 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/27719 ID: 27720 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/27720 ID: 27721 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/27721 ID: 27734 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/27734 ID: 27738 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/27738 ID: 27743 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/27743 ID: 27750 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/27750 ID: 27751 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/27751 Passed openQA tests: 39/88 (x86_64), 11/17 (i386) Skipped openQA tests: 12 of 105 -- Mail generated by check-compose: https://git.fedorahosted
Re: Orphaned packages seeking new point of contact
On 07/29/2016 07:21 PM, Kevin Fenzi wrote: > Greetings. > #topic #1607 Orphan package for "patches" > .fesco 1607 > https://fedorahosted.org/fesco/ticket/1607 I've assigned nodejs packages which have dependencies to group::nodejs-sig. > compat-libuv010 (f23) > compat-libuv010 (f24) > compat-libuv010 (f25) > compat-libuv010 (master) Needed in f23 for nodejs 0.10 f23, f24: assigned to group::nodejs-sig retired in f25 and rawhide > node-gyp (el6) > node-gyp (epel7) > node-gyp (f23) > node-gyp (f24) > node-gyp (f25) > node-gyp (master) Assigned to group::nodejs-sig I'm not sure if we still need this. > npm (el6) > npm (epel7) > npm (f23) > npm (f24) Was already retired, assigned active branches to nodejs-sig. > uglify-js1 (el6) > uglify-js1 (epel7) > uglify-js1 (f23) > uglify-js1 (f24) > uglify-js1 (f25) > uglify-js1 (master) Assigned to nodejs-sig, some modules still use this. > web-assets (el5) > web-assets (el6) > web-assets (epel7) > web-assets (f23) > web-assets (f24) > web-assets (f25) > web-assets (master) Assigned to nodejs-sig web-assets-filesystem is used by many modules as buildrequires. > ycssmin (el6) > ycssmin (epel7) > ycssmin (f23) > ycssmin (f24) > ycssmin (f25) > ycssmin (master) assigned to nodejs-sig Piotr signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] 2016-08-08 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2016-08-08 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again tomorrow! We have some more new folks we can welcome, and we can check in on the new member sponsorship procedure and the state of F25 Alpha and Test Days. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 25 Alpha/Test Days status 3. New member welcome, sponsorship, another onboarding meeting? 4. Open floor ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] 2016-08-08 @ 16:00 UTC - Fedora 25 Blocker Review
# F25 Blocker Review meeting # Date: 2016-08-08 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We currently have 1 proposed Alpha blocker and 2 proposed Beta blockers to review. There are also 3 accepted blockers to check in on. If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F25 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[HEADS UP] leveldb-1.18 in rawhide
Hi,
I'm going to build new version of LevelDB for rawhide.
$ sudo dnf repoquery --alldeps --whatrequires leveldb --queryformat="%{name}" -q
ceph-mon
ceph-osd
ceph-test
leveldb-devel
mesos
minetest
minetest-server
polyglot-chess
python-mesos
python-plyvel
python3-plyvel
I tried to rebuild all those deps in COPR:
https://copr.fedorainfracloud.org/coprs/ignatenkobrain/leveldb118/builds/
Ceph is still building, but I don't expect any problems. Mesos is
FTBFS in rawhide anyway.
I will rebuild all deps in rawhide.
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[packaging] Needs advice on using ExclusiveArch or ExcludeArch
I am currently packaging embree [0] which is required by recent release of LuxRender. The bad news is embree (https://embree.github.io/downloads.html) is only available for 64 bits architectures meaning all others i.e. i686[1] and armv7hl[2] will fail to build. Either i have to use ExclusiveArch or ExcludeArch parameter in spec file. Advice needed. References --- [0] https://bugzilla.redhat.com/show_bug.cgi?id=1364618 [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=15166172 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=15166100 -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [packaging] Needs advice on using ExclusiveArch or ExcludeArch
I think it's still possible to compile it for 32bit by disabling AVX and AVX2. Though I'm not sure about guidelines for SSE2 and AVX*. On Sun, Aug 7, 2016 at 9:03 PM, Luya Tshimbalanga wrote: > I am currently packaging embree [0] which is required by recent release > of LuxRender. The bad news is embree > (https://embree.github.io/downloads.html) is only > available for 64 bits architectures meaning all others i.e. i686[1] and > armv7hl[2] will fail to build. > > Either i have to use ExclusiveArch or ExcludeArch parameter in spec > file. Advice needed. > > References > --- > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=1364618 > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=15166172 > [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=15166100 > > -- > > Luya Tshimbalanga > Graphic & Web Designer > E: l...@fedoraproject.org > W: http://www.coolest-storm.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HEADS UP] leveldb-1.18 in rawhide
hi
sorry for the noise have tried also leveldbjni?
( see https://bugzilla.redhat.com/show_bug.cgi?id=881608 )
thanks in advance
regards
.g
Il 07/08/2016 20:17, Igor Gnatenko ha scritto:
Hi,
I'm going to build new version of LevelDB for rawhide.
$ sudo dnf repoquery --alldeps --whatrequires leveldb --queryformat="%{name}" -q
ceph-mon
ceph-osd
ceph-test
leveldb-devel
mesos
minetest
minetest-server
polyglot-chess
python-mesos
python-plyvel
python3-plyvel
I tried to rebuild all those deps in COPR:
https://copr.fedorainfracloud.org/coprs/ignatenkobrain/leveldb118/builds/
Ceph is still building, but I don't expect any problems. Mesos is
FTBFS in rawhide anyway.
I will rebuild all deps in rawhide.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HEADS UP] leveldb-1.18 in rawhide
I'm not expert in Java, but that patch is still there.
On Sun, Aug 7, 2016 at 9:15 PM, gil wrote:
> hi
>
> sorry for the noise have tried also leveldbjni?
>
> ( see https://bugzilla.redhat.com/show_bug.cgi?id=881608 )
>
> thanks in advance
>
> regards
>
> .g
>
>
> Il 07/08/2016 20:17, Igor Gnatenko ha scritto:
>>
>> Hi,
>>
>> I'm going to build new version of LevelDB for rawhide.
>>
>> $ sudo dnf repoquery --alldeps --whatrequires leveldb
>> --queryformat="%{name}" -q
>> ceph-mon
>> ceph-osd
>> ceph-test
>> leveldb-devel
>> mesos
>> minetest
>> minetest-server
>> polyglot-chess
>> python-mesos
>> python-plyvel
>> python3-plyvel
>>
>> I tried to rebuild all those deps in COPR:
>> https://copr.fedorainfracloud.org/coprs/ignatenkobrain/leveldb118/builds/
>> Ceph is still building, but I don't expect any problems. Mesos is
>> FTBFS in rawhide anyway.
>>
>> I will rebuild all deps in rawhide.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [packaging] Needs advice on using ExclusiveArch or ExcludeArch
Luya Tshimbalanga wrote: > I am currently packaging embree [0] which is required by recent release > of LuxRender. The bad news is embree > (https://embree.github.io/downloads.html) is only > available for 64 bits architectures meaning all others i.e. i686[1] and > armv7hl[2] will fail to build. > > Either i have to use ExclusiveArch or ExcludeArch parameter in spec > file. Advice needed. This software is clearly x86-only (the required SSE2 does not exist on any other architecture) and as such should be ExclusiveArch. Whether you should make it ExclusiveArch: x86_64 or whether you should also enable 32-bit x86 is up for debate. It is the usual issue of upstream not supporting non-SSE2 CPUs. Fedora i686 packages are supposed to work without SSE2 (in fact, without ANY vector instructions, even MMX and SSE), but it is nicer to the users to have the software available for some 32-bit x86 CPUs than for none at all. But either way, it clearly does not make sense to enumerate all the non-x86 architectures in ExcludeArch, ExclusiveArch is the right concept. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Pending ACLs
On Sat, Aug 06, 2016 at 07:35:04PM +0200, Kalev Lember wrote: > On 08/06/2016 05:36 PM, Richard W.M. Jones wrote: > > On Sat, Aug 06, 2016 at 03:48:36PM +0100, Fabio Alessandro Locati wrote: > >> On Thu, Aug 04, 2016 at 08:41:56PM +0100, Richard W.M. Jones wrote: > >>> Your email needs a "call to action" link, otherwise no one will know > >>> what they are supposed to do about it. In this case it's probably: > >>> > >>> https://admin.fedoraproject.org/pkgdb/acl/pending/ > >>> > >>> However I visited the above URL, logged in, and it says: > >>> > >>> Pending ACLs > >>> No pending ACLs for you > >>> > >>> So I guess this is wrong or perhaps refers to something else: > >>> > >>> ... > 3rjones > >>> ... > >> > >> Hi Richard, > >> > >> It seems like pkgdb is hiding those ACL requests on the page you linked. > >> It seems like the following requests could/should be approved by you: > >> > >> requester | req_acl | package | distro | version | approver > >> ---+-+-++-+-- > >> epienbro | commit | mingw32-gtk-vnc | Fedora | devel | rjones > >> epienbro | approveacls | mingw32-gtk-vnc | Fedora | devel | rjones > >> ktietz| approveacls | mingw32-openssl | Fedora | devel | rjones > > > > I've checked again just now, and I still don't see those ACLs. > > It still says: > > > > Pending ACLs > > > > No pending ACLs for you > > We retired all mingw32- packages a few years ago and renamed them to > mingw-, so I think pkgdb is correct here to not show these to you. Ah thanks Kalev, that makes sense. Perhaps pkgdb should reap these retired packages (although as it is hiding them, that could be correct behaviour already). 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 https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Ntfs-3g - Files treated as executable
Please use the users mailing list for these kinds of questions. https://lists.fedoraproject.org/admin/lists/users.lists.fedoraproject.org/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Sun, Aug 07, 2016 at 12:59:06AM +0200, Kevin Kofler wrote:
> Peter Robinson wrote:
> > There will be a slight change that a failure in an arch won't cancel
> > the other arches and each one will run to completion (pass/fail) but
> > the overall primary task will still fail.
>
> I don't see how wasting Koji resources on completing an already failed build
> helps anybody.
I think this was already mentioned in this thread, but anyway, the goal
is to be able to distinguish the case where just one architecture x fails to
build from the case where two or more architectures fail to build, and
architecture x was just the fastest.
> > The data we have for build failures across all the arches show that
> > not to be the case.
>
> Having been plagued by obscure architecture-specific toolchain bugs several
> times (see also my other mail in this thread), I don't think you are seeing
> the whole picture there.
Bug #1342095 is hardly earth-shattering. Simply reverting to distribution
default CFLAGS seems to work around the problem.
And please note that the plan is that by removing the need to play catch
up with koji-shadow for secondary architectures, the maintainers for those
architectures will have more time to handle actual bugs, so it's likely
that #1342095 might be handled faster in the future.
> > And in response to the "slow built times" the builders in the non
> > primary koji instance are of equivalent or faster than the x86
> > builders. EG the ppc64 builders use to be a LOT slower than x86 back
> > when we had Power6 builders, but that hasn't been the case for over 3
> > years, and the current Power8 generation builders are actually faster
> > than the x86 builders.
>
> Does that also hold for build tasks that cannot be parallelized (e.g.:
> custom specfile scripts, handwritten build scripts from upstream, Makefiles
> that do not support %{_smp_mflags} due to race conditions, etc.)?
Probably not. But how many packages do we have that A) are big, B) have broken
parallel build, C) are active and rebuild regularly? It'd get that A ∩ B ∩ C
isn't that big.
Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
