Re: EPEL support in "master" branch (aka speeding up Fedora development)
Dne 20.1.2018 v 12:27 Igor Gnatenko napsal(a): > Why I'm writing this? I want to hear from you if you think it would be good to > prohibit (or advise, or whatever mechanism would work) usage if conditionals > in > (at least) master branch to allow us to develop features faster. Thoughts? > Suggestions? I just stumbled on other counter example. In Copr you submit one SRPM and you want to have build in different chroots. This can be hardly done without conditionals. In Copr we use spec generators (pyp2rpm, gem2spec). Now we generate one spec (and SRPM). If conditionals were prohibited, then we would need to generate several SRPMs and upstream of those tools will have to maintains several templates. Miroslav signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 Self Contained Change: GifLib5
= Proposed Self Contained Change: GifLib5 = https://fedoraproject.org/wiki/Changes/GifLib5 Change owner(s): * Sandro Mani Update the giflib package to the latest giflib-5.x version (currently 5.1.4). == Detailed Description == Update the giflib package to the latest giflib-5.x version (currently 5.1.4) and rebuild all dependencies. giflib-4.x is long since obsolete, and some packages are starting to drop support for giflib-4.x (i.e. leptonica). The update is being tested in this COPR repo. https://copr.fedorainfracloud.org/coprs/smani/giflib5/builds/ == Scope == * Proposal owners: - Rebuild all dependencies, possibly with some minor patching (porting, if necessary, is usually trivial, i.e. - DGifOpenFileName(fullname) + DGifOpenFileName(fullname, NULL) - DGifCloseFile(GifFile) + DGifCloseFile(GifFile, NULL) - DGifOpenFileHandle(fh); + DGifOpenFileHandle(fh, NULL); The list of dependent packages at time of writing is: driftnet efl emacs fbida fontforge gdal giflib imlib imlib2 java-1.8.0-openjdk java-9-openjdk kdelibs kf5-khtml leptonica libextractor libgdiplus librasterlite2 libwebp MagicPoint mapserver mathgl metapixel ming mtpaint ocaml-camlimages OpenImageIO OpenSceneGraph perl-Imager perl-Prima python-gd sxiv tracker-miners vips WindowMaker xemacs xplanet * Other developers: Some help is required to do a bootstrap build of java-1.8.0-openjdk: it BuildRequires: java-1.8.0-openjdk-devel, hence a bootstrap build without giflib support is needed to be able to build against giflib-5.x (otherwise build-dependencies are not installable). * Release engineering: #7280: https://pagure.io/releng/issue/7280 * List of deliverables: N/A * Policies and guidelines: * N/A * Trademark approval: N/A -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Fedora 28 Rawhide 20180123.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 28 Rawhide 20180123.n.1. 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: lorax - 20180117.n.1: lorax-28.3-1.fc28.src, 20180123.n.1: lorax-28.4-1.fc28.src anaconda - 20180117.n.1: anaconda-28.17-1.fc28.src, 20180123.n.1: anaconda-28.18-1.fc28.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/28 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_28_Rawhide_20180123.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_28_Rawhide_20180123.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_28_Rawhide_20180123.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_28_Rawhide_20180123.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_28_Rawhide_20180123.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_28_Rawhide_20180123.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_28_Rawhide_20180123.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)
On 01/22/2018 11:58 PM, Rafal Luzynski wrote: I'd like to notify you that today I've finished my works on date formatting in glibc, that means upstream. These changes are already arriving to Fedora Rawhide (they should be there tomorrow) and will be part of Fedora 28. They will be included in glibc 2.27 (to be released on February 1), or in pre-release upstream version 2.26.9000-1145 (in Fedora Rawhide: 2.26.9000-48). Note that this is an ongoing effort. Some Romance languages will eventually use this to correct the incorrect spelling of “de April” into “d'April”. Once this happens, it will be necessary to change translation strings for these languages from “de %B” to “%B”, otherwise, the result will “de d'April”. (Yes, the meaning of %B changed in a backwards-incompatible way, and glibc upstream deliberately implemented it this way.) Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc
On 01/23/2018 05:44 PM, Adam Jackson wrote: On Tue, 2018-01-23 at 08:00 +0100, Florian Weimer wrote: On 01/22/2018 10:15 PM, Adam Jackson wrote: On Mon, 2018-01-22 at 19:19 +0100, Florian Weimer wrote: Redeclarations in system headers are expected. Do you compile with -Wsystem-headers? Or do you something else which is unusual, such as running the preprocessor separately? Not that I'm aware of. The generated cc line is: ninja: Entering directory `build' [1/17] ccache cc -Ios/libxserver_os@sta -Ios -I../os -Ixfixes -I../xfixes ccache runs the preprocessor separately. 8-) Hah! Of course it would. Thanks for the explanation. Jakub has identified the real cause, though. (When we say different things, it's more likely that he is right, as a rule of thumb.) Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help required: bootstrap-build of java-1.8.0-openjdk for giflib-5.x update
On 01/24/2018 12:10 AM, Sandro Mani wrote: I've proposed a change to update to giflib-5.x for F28+ [1] (which is an incompatible update from the current giflib-4.x). I did some initial testing in this COPR repo [1], and have hit a problem with java-1.8.0-openjdk, which has a BR on itself (java-1.8.0-openjdk-devel), resulting in it wanting to pull in also giflib-4 (since the current build is compiled against giflib-4), and hence leading to a conflict when installing the build dependencies. You could temporarily build a compat package for libgif.so.4. I think this would help to address this case and others. I don't see an inherent conflict here because OpenJDK only needs libgif.so.4 at build time, but not the -devel package for version 4. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for Wednesday's FPC Meeting (2018-01-24 18:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Wednesday at 2018-01-24 18:00 UTC in #fedora-meeting-2 on irc.freenode.net. Local time information (via. uitime): = Day: Wednesday = 2018-01-24 10:00 PST US/Pacific 2018-01-24 13:00 EST --> US/Eastern <-- 2018-01-24 18:00 GMT Europe/London 2018- 01-24 18:00 UTC UTC 2018-01-24 19:00 CET Europe/Berlin 2018-01-24 19:00 CET Europe/Paris 2018-01-24 23:30 IST Asia/Calcutta --- New Day: Thursday 2018-01-25 02:00 HKT Asia/Hong_Kong 20 18-01-25 02:00 +08 Asia/Singapore 2018-01-25 03:00 JST Asia/Tokyo 2018-01-25 04:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #654 glibc file triggers .fpc 654 https://pagure.io/packaging-committee/issue/654 #topic #691 noarch *sub*packages with arch-specific dependencies .fpc 691 https://pagure.io/packaging-committee/issue/691 #topic #693 Wiki:Packaging:RPMMacros .fpc 693 https://pagure.io/packaging-committee/issue/693 #topic #694 Packaging guidelines for application independence .fpc 694 https://pagure.io/packaging-committee/issue/694 #topic #708 Allocating a static uid and gid for openvswitch .fpc 708 https://pagure.io/packaging-committee/issue/708 #topic #710 Ruby packaging guidelines update .fpc 710 https://pagure.io/packaging-committee/issue/710 #topic #713 Forward-looking conditionals by default .fpc 713 https://pagure.io/packaging-committee/issue/713 #topic #714 let's kill file deps! .fpc 714 https://pagure.io/packaging-committee/issue/714 #topic #715 Separately building package documentation .fpc 715 https://pagure.io/packaging-committee/issue/715 #topic #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 #topic #720 Easy way of changing/removing shebangs .fpc 720 https://pagure.io/packaging-committee/issue/720 #topic #723 Guidelines for handling deprecated dependencies during review .fpc 723 https://pagure.io/packaging-committee/issue/723 #topic #726 Review for SELinux Independent Policy packaging Draft .fpc 726 https://pagure.io/packaging-committee/issue/726 = New business = #topic #729 How to handle non-informative package reviews? .fpc 729 https://pagure.io/packaging-committee/issue/729 #topic #731 Testing guidelines .fpc 731 https://pagure.io/packaging-committee/issue/731 #topic #733 'users and groups' should link to prealloc. list .fpc 733 https://pagure.io/packaging-committee/issue/733 #topic #737 Allocating a soft static uid and gid 389 for dirsrv .fpc 737 https://pagure.io/packaging-committee/issue/737 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://pagure.io/packaging-committee , e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Building software based on Firefox 58 ? Please read
at times it can be fast but for me i find it slow ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self-Introduction Christian Glombek (lorbus) / NEEDSPONSOR / NEEDREVIEWs / Let's Meet @ DevConf or FOSDEM!
On Tue, Jan 23, 2018 at 10:39 AM, Christian Glombek wrote: > Hello World! > Hi Chris! > My name is Christian Glombek (or simply Chris :) and I'd like to join the > Fedora Packagers Group. I'm currently a student of Electrical Engineering > and Business Management at RWTH University in Aachen, Germany. > My FAS and IRC handle is `lorbus` and on GitHub and Twitter I'm > `LorbusChris`. I've been using Fedora for two or so years on my daily > drivers, very much to my satisfaction. > Fedora's focus on modern concepts, especially container technology, > intrigues me. Its community to me has always seemed open, friendly, diverse > and knowledgeable. > I also feel that Fedora's sponsor Red Hat has established a symbiotic > relationship with this community, transparently supporting a quite > remarkable and rightfully successful business model. > I feel passionate about Open Source Technology and would like to > participate! > ragel-rpm / colm-rpm: > I also did some work updating the already-existing Ragel (dep of Rspamd) and > Colm (dep of Ragel) rpms and was consequently asked by current repo > maintainer Jason Taylor (jtaylor) to take over the position, which I'll > gladly do once I've found a sponsor and get the privilege of joining the > packagers' group! > I'd like to try out Modularity packaging for Ragel as it has two release > streams, stable and development, of which only the latter is in Fedora. > (I made a ragel-compat rpm for the stable release stream, which can be found > on COPR, but I believe Modularity's arbitrary branching would be a perfect > fit here!) > COPR ragel-compat: > https://copr.fedorainfracloud.org/coprs/lorbus/ragel-compat/ Thank you for your contributions with the ragel and colm packages, I am looking forward to working with you on these packages and others! JT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Wyland is a disaster
On Tue, Jan 23, 2018 at 6:56 PM, Howard Howell wrote: > Due to that last line, issued su and password and ran it again: > # lshw > Segmentation fault (core dumped) > # > Due to the fact that you're having segfaults in command-line programs as well, I'm tempted to say you've got a bigger (hardware?) problem on your hands, and that Wayland crashing is just a symptom of that larger issue. -- Jared Smith ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Wyland is a disaster
On Tue, 2018-01-23 at 12:35 -0800, Samuel Sieb wrote: > On 01/23/2018 12:22 PM, Howard Howell wrote: > > I thought there was a tool to list installed boards, but can't > > find it. Any thoughts there, other than opening up the system and > > getting the label information? > > lshw and/or lshw-gui > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Tried invoking the command. Got the prompt to install it, entered the su password, and got this response. description: Computer width: 64 bits capabilities: smp vsyscall32 *-core description: Motherboard physical id: 0 *-memory description: System memory physical id: 0 size: 15GiB *-cpu product: AMD FX(tm)-8300 Eight-Core Processor vendor: Advanced Micro Devices [AMD] physical id: 1 bus info: cpu@0 size: 1450MHz capacity: 3300MHz width: 64 bits capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp x86-64 constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate retpoline retpoline_amd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold cpufreq *-pci:0 description: Host bridge product: RD9x0/RX980 Host Bridge vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 100 bus info: pci@:00:00.0 version: 02 width: 32 bits clock: 33MHz *-pci:0 description: PCI bridge product: RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GFX port 0) vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 2 bus info: pci@:00:02.0 version: 00 width: 32 bits clock: 33MHz capabilities: pci normal_decode bus_master cap_list configuration: driver=pcieport resources: irq:24 ioport:e000(size=4096) memory:fea0- feaf ioport:c000(size=268435456) *-display description: VGA compatible controller product: Oland [Radeon HD 8570 / R7 240/340 OEM] vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 0 bus info: pci@:01:00.0 version: 00 width: 64 bits clock: 33MHz capabilities: vga_controller bus_master cap_list rom configuration: driver=radeon latency=0 resources: irq:47 memory:c000-cfff memory:fea0-fea3 ioport:e000(size=256) memory:c-d *-multimedia description: Audio device product: Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series] vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 0.1 bus info: pci@:01:00.1 version: 00 width: 64 bits clock: 33MHz capabilities: bus_master cap_list configuration: driver=snd_hda_intel latency=0 resources: irq:49 memory:fea6-fea63fff *-pci:1 description: PCI bridge product: RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 0) vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 4 bus info: pci@:00:04.0 version: 00 width: 32 bits clock: 33MHz capabilities: pci normal_decode bus_master cap_list configuration: driver=pcieport resources: irq:24 ioport:d000(size=4096) memory:fe90- fe9f ioport:d000(size=1048576) *-network description: Ethernet interface product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@:02:00.0 logical name: enp2s0 version: 0c serial: d8:50:e6:5b:cd:af size: 100Mbit/s capacity: 1Gbit/s width: 64 bits clock: 33MHz capabilities: bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation configuration: autonegotiation=
Re: net-snmp unresponsive maintainer
Re-sending my contact request with Josef added to Cc: because looks
like zodbot IRC bot on #fedora-admin lies :P
kloczek .whoowns net-snmp
zodbot kloczek: jsafrane
kloczek .fas jsafrane
zodbot kloczek: jsafrane 'Jan Šafránek'
On https://src.fedoraproject.org/rpms/net-snmp main admin is jridky :)
(shame) And .. added a lot of cleanups to %changelog entry :)
--
Hi,
I'm following
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
I'm asking for any reaction on:
https://bugzilla.redhat.com/show_bug.cgi?id=1529716
https://src.fedoraproject.org/rpms/net-snmp/pull-request/2
List of proposed changes is quite long.
%changelog
* Thu Dec 28 2017 Tomasz Kłoczko - 1:5.7.3-29
- removed Group fields
(https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections)
- remove all legacy hacks for Fedora older than 25
- remove chkconfig, initscripts and coreutils from Requires (no longer
needed)
- remove man pages .gz suffixes in %%files (it breaks building the package
with not compresses man pages or compresses using another compression
methods)
- removed no longer needed init scripts
- removed no longer needed pie patch as generating PIE code is now part
of the default cc1 spec in (/usr/lib/rpm/redhat/redhat-hardened-cc1)
- add use %%autosetup in %%prep
- fixed openssl patch (it has been patching files created by use patch -b)
- added Detect-if-mysql-has-my_load_defaults patch based on
https://sf.net/p/net-snmp/code/ci/cb268b66ee49a123ee which allows building
net-snmp against MySQL 5.7
- removed %%clean section (no longer needed)
- added use more macros in %%install and %%files
- remove %%global netsnmp_check (use rpmbuild --nocheck if you want to
disable execute %%check)
- removed PORTING from %%doc (not relevant for net-snmp Linux binary
distribution)
- moved README.mib2c to perl %%doc
- removed %%{_datadir}/snmp from perl subpackage (it is owned by libs)
- %%doc python/README instead README to python subpackage
- use --with-python-modules configure option and add fix_pythoninstall patch
instead hacks in %%build and %%install build and install python module
- removed elfutils-devel, rpm-devel, elfutils-libelf-devel, openssl-devel,
lm_sensors-devel and perl-devel from devel subpackage Requires as none of
the net-snmp header files is used any headers from those packages
- chrath hack no longer needed
- do not patch COPYRIGHT and README to utf8 using iconv and just use
patch (because be
informed when such fix is not needed when patch will reject)
- removed redundant --sysconfdir=%%{_sysconfdir} from %%configure options
- removed add -D_RPM_4_4_COMPAT to CFLAGS as now it only generated on
compile output a lot of warnings about redefining this define
(detection is define _RPM_4_4_COMPAT needed is in
configure.d/config_os_libs1)
- removed install net-snmp-tmpfs.conf as now snmpd and snmptrapd are no
longer creates pid files
- simplify not fire testing/fulltests/default/T200snmpv2cwalkall_simple on
some archs
- explicite disable libwrap (add --without-libwrap to configure option)
- added mysql %%bcond by default enabled
- remove --with-ldflags="-Wl,-z,relro -Wl,-z,now" from configure options as
-z,relro is now part of the %%__global_ldflags and -z,now is part of the
defalt linking options (/usr/lib/rpm/redhat/redhat-hardened-ld)
- added -Wl,--as-needed to LDFLAGS instead use --enable-as-needed
- added net-snmp-config.in_no_ldflags_in_--libs patch which removes LDFLAGS
from net-snmp-config
[--libs,--external-libs,--agent-libs,--external-agent-libs]
and adds passing ldflags to Extension() python fulction as extra_link_args
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, 2018-01-23 at 21:25 +, Philip Kovacs wrote: >> Can someone please elaborate on how I can control the abi tests >> directly?Where exactly can I access these and refine them on a per- >> package basis? >That text isn't talking about "fixing the tests", but about fixing the >*bugs*. It assumes that the test indicates a real issue that needs >fixing, therefore you can fix the issue in your package and cause the >test to pass. OK, thanks. The abi check canvases everything in the package and is sensitive to changes that are internal to the package. Thoser internal changes are not bugs for us to manage.Take, for example, a c/c++ package with many .so plugins or other internal libraries that provide services to the application, but are not user-facing -- the abi check sees these internal changes as noteworthy, but they really are not and should be filtered. I guess I'll have to use the waiver for now. On Tuesday, January 23, 2018 5:44 PM, Adam Williamson wrote: On Tue, 2018-01-23 at 21:25 +, Philip Kovacs wrote: > Can someone please elaborate on how I can control the abi tests > directly?Where exactly can I access these and refine them on a per- > package basis? > How to fix the tests? That text isn't talking about "fixing the tests", but about fixing the *bugs*. It assumes that the test indicates a real issue that needs fixing, therefore you can fix the issue in your package and cause the test to pass. It doesn't really cover the scenario where what the test is reporting isn't really a problem and doesn't need to be fixed. You can't resolve that from your package git repository, but you *can* submit a waiver, as discussed upthread. Additionally, as Ralph wrote, he has removed abicheck from the list of gating tests for now, so you shouldn't need to worry about abicheck failures blocking updates, as soon as Bodhi starts applying that change. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Help required: bootstrap-build of java-1.8.0-openjdk for giflib-5.x update
Hi I've proposed a change to update to giflib-5.x for F28+ [1] (which is an incompatible update from the current giflib-4.x). I did some initial testing in this COPR repo [1], and have hit a problem with java-1.8.0-openjdk, which has a BR on itself (java-1.8.0-openjdk-devel), resulting in it wanting to pull in also giflib-4 (since the current build is compiled against giflib-4), and hence leading to a conflict when installing the build dependencies. So I'd need to do a bootstrap build of java-1.8.0-openjdk without giflib support. Can someone familiar with openjdk packaging suggest the best way to proceed? My attempt to just leave out BR: giflib-devel ended up in *** SRC specified to SetupNativeCompilation LIBSPLASHSCREEN contains missing directory /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.151-3.b12.fc28.x86_64/openjdk/jdk/src/share/native/sun/awt/giflib. Stop. Note: a side-by-side of giflib-4 and giflib-5 is not possible since per upstream both install the header to /usr/include/gif_lib.h, and moving the header downstream would require patching dependent packages to tell them where to find the correct header. Thanks Sandro [1] https://fedoraproject.org/wiki/User:Smani/Changes/GifLib5 [2] https://copr.fedorainfracloud.org/coprs/smani/giflib5/builds/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Building software based on Firefox 58 ? Please read
On Tue, 23 Jan 2018 22:42:29 - "Greg Evenden" wrote: > i'd Add it but IMO COPR is to Damm slow I didn't notice any special slowness. Maybe I was just lucky. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Building software based on Firefox 58 ? Please read
i'd Add it but IMO COPR is to Damm slow ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self-Introduction Christian Glombek (lorbus) / NEEDSPONSOR / NEEDREVIEWs / Let's Meet @ DevConf or FOSDEM!
- Original Message - > From: "Christian Glombek" > To: devel@lists.fedoraproject.org > Sent: Tuesday, January 23, 2018 4:39:55 PM > Subject: Self-Introduction Christian Glombek (lorbus) / NEEDSPONSOR / > NEEDREVIEWs / Let's Meet @ DevConf or FOSDEM! > Hello World! > My name is Christian Glombek (or simply Chris :) and I'd like to join the > Fedora Packagers Group. I'm currently a student of Electrical Engineering > and Business Management at RWTH University in Aachen, Germany. > My FAS and IRC handle is `lorbus` and on GitHub and Twitter I'm > `LorbusChris`. I've been using Fedora for two or so years on my daily > drivers, very much to my satisfaction. > Fedora's focus on modern concepts, especially container technology, intrigues > me. Its community to me has always seemed open, friendly, diverse and > knowledgeable. > I also feel that Fedora's sponsor Red Hat has established a symbiotic > relationship with this community, transparently supporting a quite > remarkable and rightfully successful business model. > I feel passionate about Open Source Technology and would like to participate! > Over the past few months I've been feeding my interests in some corners of > the extended Fedora universe, mainly tinkering with RPM and Ansible Playbook > Bundle (APB) packaging and also trying out custom Atomic/OSTree builds (love > Atomic Workstation!). > RPMs: > NEEDSPONSOR > I want to get some packages into Fedora proper and I need a sponsor for that! > I'd also hugely appreciate (unofficial) reviews or any other feedback for the > following packages: > coturn-rpm: > NEEDREVIEW > BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1491492 > COPR: https://copr.fedorainfracloud.org/coprs/lorbus/coturn/ > Repo: https://github.com/LorbusChris/coturn-rpm > libreoffice-online-rpm: > NEEDREVIEW (later, WIP) > BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1494915 > COPR: https://copr.fedorainfracloud.org/coprs/lorbus/libreoffice-online/ > Repo: https://github.com/LorbusChris/libreoffice-online-rpm > Note: > The frontend part of libreoffice-online, loleaflet, uses `npm install` during > build (versioned with a npm-shrinkwrap file). From what I've read about > packaging nodejs modules, I'll probably have to manually download and add > all module sources to the rpm. WIP. > rspamd-rpm: > NEEDREVIEW (later, WIP) > BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1494914 > COPR: https://copr.fedorainfracloud.org/coprs/lorbus/rspamd/ > Repo: https://github.com/LorbusChris/rspamd-rpm > Note: > I'll have to gather some more info about bundled softwares, possibly split > out some existing dep packages. > ragel-rpm / colm-rpm: > I also did some work updating the already-existing Ragel (dep of Rspamd) and > Colm (dep of Ragel) rpms and was consequently asked by current repo > maintainer Jason Taylor (jtaylor) to take over the position, which I'll > gladly do once I've found a sponsor and get the privilege of joining the > packagers' group! > I'd like to try out Modularity packaging for Ragel as it has two release > streams, stable and development, of which only the latter is in Fedora. > (I made a ragel-compat rpm for the stable release stream, which can be found > on COPR, but I believe Modularity's arbitrary branching would be a perfect > fit here!) > COPR ragel-compat: > https://copr.fedorainfracloud.org/coprs/lorbus/ragel-compat/ > APBs: > I also like the idea of the Kubernetes Service Catalog, in conjunction with > the Ansible Service Broker (and Ansible in general) and so I did some > tinkering with Ansible Playbook Bundles, the packaging format for the > Ansible Broker: > awx-apb: > Repo: https://github.com/LorbusChris/awx-apb > Note: > APB to broker (provision/deprovision) Ansible AWX. > Can also be used as an alternative installer for AWX deployment on OpenShift. > openshift-acme-installer: > Repo: https://github.com/LorbusChris/openshift-acme-installer > Note: > Installer for https://github.com/tnozicka/openshift-acme > Non-standard privilged (cluster-admin) APB, can be used as installer, not > currently for brokering. > Eventually, I'd like to see FreeIPA, Dovecot, Postfix, Rspamd, Clamd, > NextCloud, LibreOffice Online, Prosody and Coturn all packaged for Fedora as > RPM and Docker and for K8s Service Catalog as APB for use in a little pet > project of mine: > https://github.com/contor-cloud/contor (WIP) > Expect to see me around on the IRC, too! I'll be saying hello in the relevant > channels in the coming days. > If you have any questions or maybe have a task for me at hand, please let me > know! > Attending Conferences > In December I met up with Fedora Ambassador Till Maas (till) for tea here in > Aachen and was given answers to lots of my questions regarding Fedora. > Thanks again, Till! > He also encouraged me to attend conferences, which is why I will be at: > - DevConf.cz, Brno, Jan 26-28, that's this Weekend! > - CentOS Dojo, Brussels, Feb 2 > - FOSDEM, Brussels, Feb 3 > - Config Managemen
Re: Test gating enabled in Bodhi
On Tue, 23 Jan 2018 11:06:59 +0100 Pierre-Yves Chibon wrote: > On Tue, Jan 23, 2018 at 09:42:50AM +, Richard W.M. Jones wrote: > > On Tue, Jan 23, 2018 at 10:28:14AM +0100, Pierre-Yves Chibon > > wrote: > > > Good Morning Fedorans! > > > > > > On Thursday, a new version of Bodhi was deployed that enabled > > > Bodhi to gate updates based on test results. You may notice a > > > "Test Gating Status" message in the right have side of the page. > > > > > > One thing to know about this is that there is currently a > > > confusing issue where Bodhi will say that the tests have failed > > > when the tests haven't finished running[0]. We are working on > > > solving that issue, but for now you can just wait a while and it > > > should report the result once all the tests have finished. > > > > > > There are three tests that must pass in order for updates to go > > > to stable: > > > > > > 0. dist.depcheck - to make sure the update's dependencies are > > > available. 1. dist.abicheck - to make sure the update's ABI > > > remains stable in a given Fedora release. > > > 2. AtomicCI pipeline - packages that are part of the Atomic Host > > > *and* include in their dist-git tests, must have these tests > > > passed in the AtomicCI pipeline > > > > This update cannot be pushed: > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2018-932548462e > > > > When I click on the "automated tests" it says: > > > > "Automated Test Results > > Failed to talk to Greenwave. > > The update can not be pushed: 1 of 2 required tests not found" > > > > and then the only "red" test (ie. failure) is rpmlint which is just > > a bunch of rpmlint being wrong. Nothing about "dist.depcheck" or > > "dist.abicheck" is mentioned anywhere. > > abicheck is the first test results shown in the automated tests tab > but indeed, no depcheck mentioned. Maybe someone from taskotron could > help us on this? In this particular case, I think that the update in question went from updates-testing-pending to updates-testing while taskotron was down for an updgrade on the 9th. There are no rpmdeplint results in resultsdb which is what I assume greenwave is complaining about. To be honest, we've always assumed that this situation was unlikely, verging on impossible due to the way that rpmdeplint is scheduled and run. Obviously, it's more likely than we thought and is an issue that we'll need to address going forward before gating can be enabled for everything. Actually, all of these issues are a bit surprising and there are several things which have gone from "eh, nobody cares. we'll get around to it someday" to "we should probably get that figured out now-ish" due to the issues raised around the gating in bodhi. Tim pgp4aAexCmlR9.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 924 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168 rubygem-crack-0.3.2-2.el6 814 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb mcollective-2.8.4-1.el6 786 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9 thttpd-2.25b-24.el6 396 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac libbsd-0.8.3-2.el6 125 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92 libmspack-0.6-0.1.alpha.el6 45 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e optipng-0.7.6-6.el6 27 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598 monit-5.25.1-1.el6 17 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462 heimdal-7.5.0-1.el6 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fde8252ab7 python-bottle-0.12.13-1.el6 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4 rootsh-1.5.3-17.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ba6bfc5d8 wordpress-4.9.2-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing GraphicsMagick-1.3.28-1.el6 distribution-gpg-keys-1.18-1.el6 fedfind-4.0.0-1.el6 mozilla-https-everywhere-2018.1.11-1.el6 Details about builds: GraphicsMagick-1.3.28-1.el6 (FEDORA-EPEL-2018-1049ca4872) An ImageMagick fork, offering faster image generation and better quality Update Information: Latest stable release, includes many bug and security fixes. See also http://www.graphicsmagick.org/NEWS.html#january-20-2017 References: [ 1 ] Bug #1473729 - CVE-2017-11102 GraphicsMagick: Input validation failure in ReadOneJNGImage function may cause denial of service [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1473729 [ 2 ] Bug #1473741 - CVE-2017-11139 GraphicsMagick: double free vulnerabilities in the [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1473741 [ 3 ] Bug #1473752 - CVE-2017-11140 GraphicsMagick: Resource exhaustion denial of service in ReadJPEGImage function [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1473752 [ 4 ] Bug #1475454 - CVE-2017-11637 GraphicsMagick: NULL pointer dereference in WritePCLImage() in coders/pcl.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1475454 [ 5 ] Bug #1475458 - CVE-2017-11636 GraphicsMagick: Heap based buffer over-write in WriteRGBImage in coders/rgb.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1475458 [ 6 ] Bug #1475490 - CVE-2017-11641 GraphicsMagick: Memory Leak in the PersistCache in magick/pixel_cache.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1475490 [ 7 ] Bug #1475498 - CVE-2017-11643 GraphicsMagick: Heap based over-write in WriteCMYKImagefunction in coders/cmyk.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1475498 [ 8 ] Bug #1484483 - CVE-2017-13147 GraphicsMagick: Allocation failure in ReadMNGImage function in coders/png.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1484483 [ 9 ] Bug #1512038 - CVE-2017-16669 GraphicsMagick: Heap buffer over-write in AcquireCacheNexus function in magick/pixel_cache.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1512038 [ 10 ] Bug #1512049 - CVE-2017-16353 GraphicsMagick: ImageMagick, GraphicsMagick: memory information disclosure in DescribeImage function in magick/describe.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1512049 [ 11 ] Bug #1528037 - CVE-2017-17782 GraphicsMagick: heap-based buffer over-read in ReadOneJNGImage function in coders/png.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1528037 [ 12 ] Bug #1528051 - CVE-2017-17783 GraphicsMagick: heap based buffer over-read in ReadPALMImage in coders/palm.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1528051 [ 13 ] Bug #1529535 - CVE-2017-17915 GraphicsMagick: Memory leak in the function ReadMNGImage in coders/png.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1529535 [ 14 ] Bug #1529557 - CVE-2017-17913 GraphicsMagick: stack-based buffer over-read in WriteWEBPImage in coders/webp.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1529557 [ 15 ] Bug #1529580 - CVE-2017-17912 GraphicsMagick: GraphicsMagick: heap-based buffer over-read in ReadNewsProfile in coders/tiff.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1529580 [ 16 ] Bug #1536951 - GraphicsMagick: 2018-5685 GraphicsMagick: Infinite loop and application hang in coders/bmp.c:ReadBMPImage [epel-all] https://bugzilla.red
Split valgrind-tools-devel from valgrind-devel package
Hi, With valgrind-3.13.0-15.fc28 the valgrind-devel package only contains the development headers needed for building valgrind aware applications. So it only contains the stand alone headers valgrind.h, callgrind.h, drd.h, helgrind.h and memcheck.h that have the client request macros that give hints to the valgrind tools. I build various packages locally that BuildRequire valgrind-devel to make sure they only required these headers. valgrind-tools-devel contains all development files, headers and static libraries, to build valgrind tools. Currently there is no package in Fedora that needs those files. Building "out of tree" valgrind tools isn't really supported because the tools need to be linked staticly and upstream doesn't guarantee API. So such tools would have to be rebuild for every new valgrind release. The new setup means that valgrind-devel is only 80K now with valgrind-tools-devel containing all the big static libraries. Please let me know if you use the valgrind-devel package and the new setup gives you any trouble. Thanks, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, 2018-01-23 at 18:12 +, Richard W.M. Jones wrote: > The problem for the OCaml packages is missing tests or tests that > haven't been run: > > https://bodhi.fedoraproject.org/updates/FEDORA-2018-932548462e > https://bodhi.fedoraproject.org/updates/FEDORA-2018-ecd3541af9 > > BTW these both really need to be pushed as soon as possible because > they fix a license violation. Yes, we're looking into that too - see https://github.com/fedora-infra/bodhi/issues/2133 for some discussion. Basically sometimes Taskotron tests for some package or other just don't run for some transient reason - some bit of the process is down or not working correctly, and because it's all fedmsg-driven, there's really only one shot and if the tests don't trigger correctly at the time they should, nothing goes back and re-triggers them later. Improving this has never been a high priority because it hasn't really mattered a lot to anyone...until now. The policy as currently implemented basically means "the update *only* passes if we can find a 'pass' for each of the required tests". So if one isn't run, the update fails. The initial thought we - we being Tim, Kamil, Josef, Ralph and I - had is to simply invert the policy, if we can, so it becomes "the update passes *unless* we can find a 'fail' for any of the required tests". So all updates would be push-able (so far as this mechanism is concerned, ignoring all the old ones) until one of the gating tests definitely failed. If we can't do that, we're going to just have to disable the gating again until this is sorted out; we're definitely of the opinion that Taskotron doesn't yet provide enough of a solid guarantee that all the tests will be run for a policy which *assumes* that will be the case to be viable. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
net-snmp unresponsive maintainer
Hi,
I'm following
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
I'm asking for any reaction on:
https://bugzilla.redhat.com/show_bug.cgi?id=1529716
https://src.fedoraproject.org/rpms/net-snmp/pull-request/2
List of proposed changes is quite long.
* Thu Dec 28 2017 Tomasz Kłoczko - 1:5.7.3-29
- removed Group fields
(https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections)
- remove all legacy hacks for Fedora older than 25
- remove chkconfig, initscripts and coreutils from Requires (no longer needed)
- remove man pages .gz suffixes in %%files (it breaks building the package
with not compresses man pages or compresses using another compression
methods)
- removed no longer needed init scripts
- removed no longer needed pie patch as generating PIE code is now
part default cc1
spec in (/usr/lib/rpm/redhat/redhat-hardened-cc1)
- add use %%autosetup in %%prep
- fixed openssl patch (it has been patching files created by use patch -b)
- added Detect-if-mysql-has-my_load_defaults patch based on
https://sf.net/p/net-snmp/code/ci/cb268b66ee49a123ee which allows
building net-snmp
against MySQL 5.7
- removed %%clean section (no longer needed)
- added use more macros in %%install and %%files
- remove %%global netsnmp_check (use rpmbuild --nocheck if you want to disable
execute %%check)
- removed PORTING from %%doc (not relevant for net-snmp Linux binary
distribution)
- moved README.mib2c to perl %%doc
- removed %%{_datadir}/snmp from perl subpackage (it is ownd by libs)
- %%doc python/README instead README to python subpackage
- use --with-python-modules configure option and add fix_pythoninstall
patch instead
hacks in %%build and %%install build and install python module
- removed elfutils-devel, rpm-devel, elfutils-libelf-devel,
openssl-devel, lm_sensors-devel and perl-devel from devel subpackage
Requires as none of the net-snmp header files is used any headers from
those packages
- chrath hack no longer needed
- do not patch COPYRIGHT and REAME to utf8 using icong and just use
patch (because be
informed when such fix is not needed when patch will reject)
- removed redundant --sysconfdir=%%{_sysconfdir} from %%configure options
- removed add -D_RPM_4_4_COMPAT to CFLAGS (detection _RPM_4_4_COMPAT
define is needed is in configure.d/config_os_libs1) as now it only only
generated on compile output a lot of warnings about redefine this define
- removed install net-snmp-tmpfs.conf as now snmpd and snmptrapd are
no longer creates
pid files
- simplify not fire
testing/fulltests/default/T200snmpv2cwalkall_simple on some archs
- explicite disable libwrap (add --without-libwrap to configure option)
- added mysql %%bcond by default disabled
- remove --with-ldflags="-Wl,-z,relro -Wl,-z,now" from configure
options as -z,relro is now
part of the %__global_ldflags and -z,now is part of the defalt linking options
(/usr/lib/rpm/redhat/redhat-hardened-ld)
- added -Wl,--as-needed to LDFLAGS instead use --enable-as-needed
- added net-snmp-config.in_no_ldflags_in_--libs patch which removes LDFLAGS from
net-snmp-config
[--libs,--external-libs,--agent-libs,--external-agent-libs] and adds
passing ldflags to Extension() python fulction as extra_link_args
- remove perl(:MODULE_COMPAT_%(eval "`%%{__perl} -V:version`"; echo
$version)) from agent-libs
Requires as now libperl library automatically has SOANME dependency
kloczek
--
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, 2018-01-23 at 21:25 +, Philip Kovacs wrote: > Can someone please elaborate on how I can control the abi tests > directly?Where exactly can I access these and refine them on a per- > package basis? > How to fix the tests? That text isn't talking about "fixing the tests", but about fixing the *bugs*. It assumes that the test indicates a real issue that needs fixing, therefore you can fix the issue in your package and cause the test to pass. It doesn't really cover the scenario where what the test is reporting isn't really a problem and doesn't need to be fixed. You can't resolve that from your package git repository, but you *can* submit a waiver, as discussed upthread. Additionally, as Ralph wrote, he has removed abicheck from the list of gating tests for now, so you shouldn't need to worry about abicheck failures blocking updates, as soon as Bodhi starts applying that change. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, 2018-01-23 at 14:16 -0500, Matthew Miller wrote:
> On Tue, Jan 23, 2018 at 12:25:56PM -0600, Rex Dieter wrote:
> > > There are three tests that must pass in order for updates to go to stable:
> > > 0. dist.depcheck - to make sure the update's dependencies are available.
> > > 1. dist.abicheck - to make sure the update's ABI remains stable in a
> > >given Fedora release.
> >
> > ...
> > > Finally, if it turns out you need to push an update through despite of the
> > > test results, you can do so using waiver-cli (dnf install waiverdb-cli).
> > > We are working on integrating this into Bodhi itself, making this easier.
> >
> > I think it unwise to make item 1 a mandatory item at this point. I'd argue
> > a large number of packages do not provide public api/abi that's worth
> > worrying about in this regard.
>
> I think we should definine a set of packages where we care about this,
> and enable it on a case-by-case basis and make it advisory otherwise.
I think we could probably do something a *bit* less icky than a
completely manual package list. What I thought of as a very simple
initial heuristic would be to only care about changes in "any shared
object installed to /usr/lib or /usr/lib64", optionally we could
restrict that further to "in a critpath package". That's installed
*directly to those directories*, not to any subdirectories of them.
This would certainly be less than the set of things we *should* care
about, because there are various mechanisms by which a shared object
that's not directly in %{libdir} can have a public ABI of some kind
(ldconfig snippets, etc). But it would at least be something to start
with...unless I'm missing something.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Building software based on Firefox 58 ? Please read
On Tue, 23 Jan 2018 22:17:29 +0100 Robert-André Mauchin wrote: > If you're interested, I provide a weekly release of Firefox Nightly > on COPR (with the latest NSPR and NSS), compiled from source and with > the Fedora patches: > https://copr.fedorainfracloud.org/coprs/eclipseo/firefox-nightly/ > > It works great, I use it daily. I might at that. I used to tune the configuration for nightly to eliminate the functionality I didn't use. With the new configuration using python, there is no .mozconfig, and many of the configuration options seem to have evaporated. The options in the new mozconfig are few and generic. And I might just stop using nightly all together, and stick with the Fedora provided firefox. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unannounced SONAME bump in tinyxml2
On Tue, Jan 23, 2018 at 09:01:56PM -, François Cami wrote: > Okay, so I'm officially confused. > https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master > says: > "For updates to rawhide packages, Maintainers SHOULD: > (...) > A week in advance, notify maintainers who depend on their package to rebuild > when there are abi/api changes that require rebuilds in other packages or > offer to do these rebuilds for them > " > > so while I should have notified the affected packages' maintainers a week in > advance, I would have notified fedora-devel if that was stated there. > > Should we update the update policy? Rule of thumb: more communication is better. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tuesday, 23 January 2018 at 20:16, Matthew Miller wrote: > On Tue, Jan 23, 2018 at 12:25:56PM -0600, Rex Dieter wrote: > > > There are three tests that must pass in order for updates to go to stable: > > > 0. dist.depcheck - to make sure the update's dependencies are available. > > > 1. dist.abicheck - to make sure the update's ABI remains stable in a > > >given Fedora release. > > ... > > > Finally, if it turns out you need to push an update through despite of the > > > test results, you can do so using waiver-cli (dnf install waiverdb-cli). > > > We are working on integrating this into Bodhi itself, making this easier. > > I think it unwise to make item 1 a mandatory item at this point. I'd argue > > a large number of packages do not provide public api/abi that's worth > > worrying about in this regard. > > I think we should definine a set of packages where we care about this, > and enable it on a case-by-case basis and make it advisory otherwise. That makes sense. How about we start with critical path packages? Alternatively, libraries which a lot of of other packages depend on would be good candidates. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
Can someone please elaborate on how I can control the abi tests directly?Where exactly can I access these and refine them on a per-package basis? How to fix the tests? The tests are all in your hand, you can fix the dist.depcheck and dist.abicheck by adjusting the update or the build and you can fix the package level testing since the tests are stored in the dist-git repository of the package itself. You have the control on the tests. On Tuesday, January 23, 2018 2:16 PM, Matthew Miller wrote: On Tue, Jan 23, 2018 at 12:25:56PM -0600, Rex Dieter wrote: > > There are three tests that must pass in order for updates to go to stable: > > 0. dist.depcheck - to make sure the update's dependencies are available. > > 1. dist.abicheck - to make sure the update's ABI remains stable in a > > given Fedora release. > ... > > Finally, if it turns out you need to push an update through despite of the > > test results, you can do so using waiver-cli (dnf install waiverdb-cli). > > We are working on integrating this into Bodhi itself, making this easier. > I think it unwise to make item 1 a mandatory item at this point. I'd argue > a large number of packages do not provide public api/abi that's worth > worrying about in this regard. I think we should definine a set of packages where we care about this, and enable it on a case-by-case basis and make it advisory otherwise. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Building software based on Firefox 58 ? Please read
On mardi 23 janvier 2018 21:30:07 CET stan wrote: > On Tue, 23 Jan 2018 13:02:47 +0100 > Kai Engert wrote: > > > > The change > > of default has been applied to the NSS library in Fedora 28 > > (currently Rawhide). > > > I compile nightly (future 59) from a local hg repository. After I > install it, when I try to start it, it tells me XPCOM not found. But > if I run it from the object directory where it was built, it runs fine, > though unlike the rawhide version of firefox, if I click on links in > emails, they don't open. I have to cut and paste them. > If you're interested, I provide a weekly release of Firefox Nightly on COPR (with the latest NSPR and NSS), compiled from source and with the Fedora patches: https://copr.fedorainfracloud.org/coprs/eclipseo/firefox-nightly/ It works great, I use it daily. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self-Introduction Christian Glombek (lorbus) / NEEDSPONSOR / NEEDREVIEWs / Let's Meet @ DevConf or FOSDEM!
On Tuesday, 23 January 2018 at 16:39, Christian Glombek wrote: > Hello World! Hello, Chris! Welcome to Fedora! Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Starting Boost 1.66.0 rebuilds in f28-boost side tag
On 23 Jan 2018 15:39, "Jonathan Wakely" wrote: As happens for most releases, I'm updating Boost in rawhide and rebuilding the affected packages in a side tag (f28-boost). https://fedoraproject.org/wiki/Changes/F28Boost166 If you maintain a package that depends on Boost please coordinate any updates with me, so that any changes you make in the main f28 target don't invalidate the rebuilds I'm doing in f28-boost. I've already identified about a dozen packages that are FTBFS in rawhide, but only two are due to the Boost update (dssp and domoticz). The rest are due to package bugs that cause linker errors now the rpm build flags default to -z defs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Last year I packaged the header only boost library nowide Do you know if that's been included upstream or if I need to do anything to align with your update? It is used for the facter3 update. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unannounced SONAME bump in tinyxml2
> announcement should be made here too Okay, so I'm officially confused. https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master says: "For updates to rawhide packages, Maintainers SHOULD: (...) A week in advance, notify maintainers who depend on their package to rebuild when there are abi/api changes that require rebuilds in other packages or offer to do these rebuilds for them " so while I should have notified the affected packages' maintainers a week in advance, I would have notified fedora-devel if that was stated there. Should we update the update policy? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Redirects for wiki pages moved to docs [was Re: ABI gate: internal-only shared object]
On Tue, Jan 23, 2018 at 11:42:57AM -0500, Matthew Miller wrote: > > We could either look at modifying the ExternalRedirecct > > extension to be something like DocsRedirect and hard-code the Annnd https://pagure.io/fedora-infrastructure/issue/6650 -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposed Fedora packaging guideline: More Go packaging
> "nm" == nicolas mailhot writes: nm> I don't know about EPEL6, but we use it as-is in EL7 and it works nm> just as well (except maybe for the %autosetup bits but IIRC that's nm> autosetup which is broken in EL7). I had ported autosetup to EPEL6 and then at the next release the macros showed up (without any discussion) in base RHEL6. So they should be there. I'm not entirely sure what's actually broken about %autosetup in EL7, though; I hadn't heard about breakage before this. epel-rpm-macros could conceivably carry %epel_autosetup or something which contains fixes. I mostly understand the internals of %autosetup so maybe there's something I can do. nm> Maybe it also works in EPEL 6 but I've never tried it. I guess it nm> depends mostly on the level of lua support in EL6 rpm and nm> rpm-related tools now the forge macro code is lua only. I think it would be worth a try. In my experience not all that much has changed in the Lua interfaces since RHEL6 and even RHEL5. (EL5 just didn't have sources and patches in the Lua namespace.) nm> For my part I doubt I'll ever use it in EL6 since I did it for Go nm> and the EL6 Go stack is really too old for a merge to be nm> interesting. Well, sure, Go on EL6 is probably out but these macros were at least presented as being far more general, and I'm sure there are plenty of EPEL6 packages which could benefit. Potential anything that packages a git snapshot of something. nm> I'm afraid my knowledge of recent fedpkg enhancements is too sparse nm> to be of any use there. Though I'm not opposed to the idea at all. It's just worth a brainstorm, I think. I can imagine that loads of people would love it if fedpkg could just auto-bump the bits necessary to update a package to today's git head or some specific commit or something like that. Before we didn't really have a good standard way to format a spec when you're using a checkout. Now Doesn't necessarily have to start in fedpkg, either. A standalone utility for doing a couple of things like that could be useful as a prototype. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EPEL support in "master" branch (aka speeding up Fedora development)
On Tue, Jan 23, 2018 at 02:03:26PM -0600, Jason L Tibbitts III wrote: > In the end there was basically no good argument for _not_ doing it but > every time I touch something like this someone crawls out of the > woodwork to flame me. So I end up hesitating instead of doing anything > and then I run out of free time. I promise whatever cover I can provide against that situation happening in the future. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security updates and batched pushes
On 01/18/2018 10:13 AM, Kevin Kofler wrote: > But whom does this help? There are still updates going out daily, the > repodata download cost is still there, the notifications too if you aren't > doing client-side batching (and if you are, you don't need server-side > batching to begin with). It would help people with more minimal package sets more often. On days with just a handful of updates, it's possible that some users don't use any of them and thus don't have to get notified. There is some discussion around possibly forming a formal policy around batching updates[0]. If we did batch updates more then users would more often get days when they don't need to download metadata, which would be nice. [0] https://pagure.io/fesco/issue/1820 signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Wyland is a disaster
On 01/23/2018 12:22 PM, Howard Howell wrote: I thought there was a tool to list installed boards, but can't find it. Any thoughts there, other than opening up the system and getting the label information? lshw and/or lshw-gui ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On 01/23/2018 01:19 PM, Ralph Bean wrote: > Hopefully the Bodhi maintainers can have a look; Bodhi may be caching > the decision here. IIRC, there's a cronjob to synchronize on the > Bodhi side. Correct - currently Bodhi polls Greenwave every 6 hours, so it could take a bit for it to notice the decision change. We do have a plan to make Bodhi listen for Greenwave fedmsgs so we don't have to rely on slow polling, so this delay should improve in the future. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Building software based on Firefox 58 ? Please read
On Tue, 23 Jan 2018 13:02:47 +0100 Kai Engert wrote: > The change > of default has been applied to the NSS library in Fedora 28 > (currently Rawhide). I compile nightly (future 59) from a local hg repository. After I install it, when I try to start it, it tells me XPCOM not found. But if I run it from the object directory where it was built, it runs fine, though unlike the rawhide version of firefox, if I click on links in emails, they don't open. I have to cut and paste them. Nightly used to work just fine from an install in /usr/local, and links would open also. Would this changed behavior be related to the above change in rawhide? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposed Fedora packaging guideline: More Go packaging
- Mail original - De: "Jason L Tibbitts III" > "nm" == nicolas mailhot writes: >nm> And the forge macros are now available since >nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to upstream >nm> renaming the file). Heartfelt thanks to Jason Tibbitts ! > Please don't forget to let me know when it's time to start thinking > about pushing this down to F27. And maybe F26. And as far as I can > tell it should work with only minor modification in EPEL7 (via > epel-rpm-macros). I don't know about EPEL6, but we use it as-is in EL7 and it works just as well (except maybe for the %autosetup bits but IIRC that's autosetup which is broken in EL7). In fact it has probably been used more heavily in EL7 than in fedora-devel so far. Maybe it also works in EPEL 6 but I've never tried it. I guess it depends mostly on the level of lua support in EL6 rpm and rpm-related tools now the forge macro code is lua only. I'm pretty sure many of the problems in the early versions of the macro were due to non-lua code and its interactions with lua code once the lua-ification started. It's a good idea to let people play with it in fedora-devel maybe a month, in case I missed something, but from a technical POW I'm prety sure it could be merged up to EL7 now. I'll submit fedora-devel specific tweaks later (just like I submitted bitkeeper.org support today), right now the code is distro-agnostic. For my part I doubt I'll ever use it in EL6 since I did it for Go and the EL6 Go stack is really too old for a merge to be interesting. Anyway I'll certainly let you know when I feel the time is right (but do not block on me!) > Finally, we should also talk about whether there is any integration or > automation possible between fedpkg and specfiles configured with these > macros. I'm afraid my knowledge of recent fedpkg enhancements is too sparse to be of any use there. Though I'm not opposed to the idea at all. Thanks again! -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EPEL support in "master" branch (aka speeding up Fedora development)
On Tue, 2018-01-23 at 14:03 -0600, Jason L Tibbitts III wrote: > > > > > > "SB" == Sérgio Basto writes: > > SB> Can't we fix things on EPEL, to speed up Fedora devel ? > > We can try. See the macro work I've done (though the real work there > was against EPEL5, which is fortunately forgotten now). you did an excellent job IMO and also IMO is the (best) way . > SB> another story that is bugging me is python2 packages for example > [1] > SB> if we want call it python2-foo , so we have to guarantee that > rule > SB> also applies on RHEL(s) / Centos . > > I worked up a proposal about this a while ago: > https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages > > In the end there was basically no good argument for _not_ doing it > but > every time I touch something like this someone crawls out of the > woodwork to flame me. So I end up hesitating instead of doing > anything > and then I run out of free time. > > Right now I still have too much other Fedora work to do, but maybe I > can > find a few minutes to put a couple of these packages in. I did go > ahead > and file four requests for the four packages listed in that proposal > (noting that python2-setuptools does exist on EL7 so only an EL6 > branch > for that one). > - J< -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Wyland is a disaster
On Mon, 2018-01-22 at 19:53 +, Tom Hughes wrote: > On 22/01/18 15:58, Adam Williamson wrote: > > > I have a dual monitor setup with both monitors rotated, using an > > NVIDIA > > adapter (9600 GT). Works fine, uses Wayland. Again, you need to be > > *very specific* about graphics issues. They are very often very > > specific to the exact hardware in use - down to the model of the > > graphics card and which specific outputs are used. > > 1 x NVIDIA Corporation G84 [GeForce 8600 GT] > > with DVI-I-1 connected to 2560x1600 panel > and DVI-I-2 connected to 1600x1200 panel rotated right > > 1 x NVIDIA Corporation GT218 [GeForce 210] > > with DVI-I-1-3 connected to 1600x1200 panel rotated right > > I can't see any obvious indication in the logs of why it fell back > but > if it's not rotation maybe it's having multiple cards? > > 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 My setup is as follows: AMD Fx(tm)-8300 eight-core processor x8 64-bit AMD Oland graphics Gnome 3.24.2 976GB disk Dual monitors ViewSonic 23" Primary Samsung Electric Company 23" Fedora 26 Wayland (normal login, but Xorg login has similar issues) Programs experiencing issues: PixyMon after rebuild crashes Gscheme simply goes away System updated at each prompt, including today. Running Gschem by invoking it from a terminal provides no unusual information. Tried on both monitors. LibreOffice Calc has died once or twice, not sure, can't repeat that. Occasionally rapid mouse movement to the Activities bar causes logout. Can't get repeatable to determine if any application causes it. Frequently my use has up to 20 tabs open in firefox, evolution up (like now), and one or two other applications open simultaneously, like now I have settings showing the display info. Checking jounalctl and dmesg has not revealed anything pertinent. Can you gentlefolk suggest anyplace else to look? Or is there any more information you need? I thought there was a tool to list installed boards, but can't find it. Any thoughts there, other than opening up the system and getting the label information? Regards, Les H ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EPEL support in "master" branch (aka speeding up Fedora development)
> "SR" == Samuel Rakitničan writes: SR> I think conditionals should be documented with more examples as well SR> [1], in order to minimize such bugs. Specific examples of what you'd like to see are certainly welcome. Feel free to file tickets at https://pagure.io/packaging-committee. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EPEL support in "master" branch (aka speeding up Fedora development)
> "SB" == Sérgio Basto writes: SB> Can't we fix things on EPEL, to speed up Fedora devel ? We can try. See the macro work I've done (though the real work there was against EPEL5, which is fortunately forgotten now). SB> another story that is bugging me is python2 packages for example [1] SB> if we want call it python2-foo , so we have to guarantee that rule SB> also applies on RHEL(s) / Centos . I worked up a proposal about this a while ago: https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages In the end there was basically no good argument for _not_ doing it but every time I touch something like this someone crawls out of the woodwork to flame me. So I end up hesitating instead of doing anything and then I run out of free time. Right now I still have too much other Fedora work to do, but maybe I can find a few minutes to put a couple of these packages in. I did go ahead and file four requests for the four packages listed in that proposal (noting that python2-setuptools does exist on EL7 so only an EL6 branch for that one). - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, Jan 23, 2018 at 12:25:56PM -0600, Rex Dieter wrote: > > There are three tests that must pass in order for updates to go to stable: > > 0. dist.depcheck - to make sure the update's dependencies are available. > > 1. dist.abicheck - to make sure the update's ABI remains stable in a > >given Fedora release. > ... > > Finally, if it turns out you need to push an update through despite of the > > test results, you can do so using waiver-cli (dnf install waiverdb-cli). > > We are working on integrating this into Bodhi itself, making this easier. > I think it unwise to make item 1 a mandatory item at this point. I'd argue > a large number of packages do not provide public api/abi that's worth > worrying about in this regard. I think we should definine a set of packages where we care about this, and enable it on a case-by-case basis and make it advisory otherwise. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
koschei interpertation; was: Re: -z defs linker flag activated in Fedora rawhide
On Tue, 23 Jan 2018, Daniel P. Berrange wrote: > What needs to be done for this ? I see my package "libvirt" present > in its UI > > https://apps.fedoraproject.org/koschei/package/libvirt > > but it says > > "Package is currently ineligible for scheduling due to following reasons: looking at the 'EPEL 7' tab, I see: Base buildroot for EPEL 7 is not installable. Dependency problems: nothing provides requested redhat-release-everything Hunh? -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Proposed Fedora packaging guideline: More Go packaging
- Mail original - De: "Mátyás Selmeci" Hi, > This looks pretty cool! Thanks for the feedback! > One thing I notice in the limitations section of > your draft is a lot of "we can't do XXX due to lack of release > discipline..." > Do you have any recommendations for Go programmers on how to structure > their software so that it is easy to package? If there is an interest I can add a section on how to make a Go project easier to package, sure. It won't be earth-shattering, just the Go declination of basic common sense rules that are needed in any coding language, that many Go projects already apply (unfortunately not all of them): — do not change your import path every other month — do not make your code accessible through multiple import paths – only use smallcaps in your import path (I know some systems are case insensitive. Many others are NOT) – communicate clearly the canonical import path of the project at the top of your README.md — if you absolutely need to change your import path fix your code to use the new import path do not rely on http redirections – that includes testing and example code — do not add a .git suffix to your import path — use _testdata for all the material needed by unit test – put your example code in _examples (with subdirectories if you ship several examples). Do not use creative unusual names such as tutorial. – do not pepper your subdirectories with .md files. Keep documentation in the project root or in a docs root subdirectory if there is too much of it — add a one-line summary and a least a § describing what your project does at the top of your README.md — choose licenses already vetted by Fedora or Debian https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses – add a licensing file named LICENSE — use unmodified plaintext canonical licensing texts, that state the LICENSE name at the top of the file — if you absolutely want to add an extension to make Windows happy, use LICENSE.txt — if you absolutely want to name your licensing file something else, please do not use something.md — do not hide your licensing terms in README.md, do not refer to a license by name without providing its text – do releases — do releases, even for minor fixes. If you haven't felt the need to touch a project for months its latest state should be released! — do releases, even for projects that can only be called through another project. Do not rely on this other project to set code state through vendoring (that's easy to do, just propagate the tip project version to the ancillary projects at release time, like kubernetes does) – use semver for your releases https://semver.org/ Distributors and godep will thank you – if your project is in git, use a different branch for every major version of your project — if your project is in git, tag your release x.y.z as x.y.z, or vx.y.z, never as vx.y.zprettybeta. Versions and version tags are not the right place to document a project maturity. — numbers are cheap, never reuse the same number for a pre-release and a final release, increase the minor version! – please version your import paths with each major release (gopkg.in is good for that) – use releases of the projects you depend on — never depend on a project that already depends on you (otherwise software dependencies stop being a nice directed acyclic graph and you get into dependency loop hell. That's a nasic software engineering golden rule, not respecting it will bite you sooner or later with or without linux distros, despite vendoring) – if for some reason, one of the projects you depend on does not release, please ask nicely it to do so – if for some reason you need a code state in tip which is not in a release, please inform the origin you'd like it to do a release, and switch to this release as soon as it is available – never depend on a commit state somewhere between two releases — document the major versions of the stuff you depend on somewhere easy to find. If a major version is only usable past as specific minor version, document it – add a unit test that detects if the project you depend on is missing the part that requires being after this minor version – if your project provides wrappers, connexion glue or anything similar to many many many other projects keep the code for each other project in a separate subdirectory (Go package) so it can be desactivated without impacting the rest of your code if the other project ode has a problem. — never add changes to the projects you reuse, submit the changes to those projects — if you absolutely need to change a project you reuse, fork it cleanly with a new import path so distributors do not accidentally reinject the original project — don't forget to rebase your code on the original project if you don't have the energy to maintain your own fork – rebase to the latest minor version of every project you depend on at release time. Do not let changes accumulate ti
Re: Looking for contact with Daniel Veillard libxml2 maintainer
On 23 January 2018 at 17:04, wrote: [..] >> Strange only is that looks like this bug already is known more than year! > > > Looks like two years... I followed the chain of links in the Red Hat bugs, > which claim this is already reported as > https://bugzilla.gnome.org/show_bug.cgi?id=762100 and fixed by > https://git.gnome.org/browse/libxml2/commit/?id=bdd66182ef53fe1f7209ab6535fda56366bd7ac9. > If that's correct (a big "if" ;) then our libxml2 package should not be > vulnerable. (I had an issue with reset password) Just opened https://bugzilla.gnome.org/show_bug.cgi?id=792840 kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unannounced SONAME bump in tinyxml2
François Cami wrote: > On Tue, Jan 23, 2018 at 2:48 PM, Igor Gnatenko > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> https://src.fedoraproject.org/rpms/tinyxml2/c/3600750a8f1b0eaa6cab346496fd75a07 >> ea749cb > > This was announced to all package owners depending on tinyxml2 announcement should be made here too -- rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On 23 January 2018 at 19:22, Ralph Bean wrote:
> On Tue, Jan 23, 2018 at 06:35:45PM +0100, Rafael dos Santos wrote:
> > I get this error after clicking the authorization link:
> >
> > [16450:16491:0123/182437.407698:ERROR:browser_gpu_
> channel_host_factory.cc(120)]
> > Failed to launch GPU process.
> > Created new window in existing browser session.
> > 127.0.0.1 - - [23/Jan/2018 18:24:37] "GET
> > /?error_description=Unknown+client+ID&error=unauthorized_client
> HTTP/1.1"
> > 200 47
> > Traceback (most recent call last):
> > File "/usr/bin/waiverdb-cli", line 11, in
> > load_entry_point('waiverdb==0.4.0', 'console_scripts',
> 'waiverdb-cli')()
> > File "/usr/lib/python2.7/site-packages/click/core.py", line 722, in
> > __call__
> > return self.main(*args, **kwargs)
> > File "/usr/lib/python2.7/site-packages/click/core.py", line 697, in
> main
> > rv = self.invoke(ctx)
> > File "/usr/lib/python2.7/site-packages/click/core.py", line 895, in
> invoke
> > return ctx.invoke(self.callback, **ctx.params)
> > File "/usr/lib/python2.7/site-packages/click/core.py", line 535, in
> invoke
> > return callback(*args, **kwargs)
> > File "/usr/lib/python2.7/site-packages/waiverdb/cli.py", line 102, in
> cli
> > if not resp.ok:
> > AttributeError: 'NoneType' object has no attribute 'ok'
>
> ACK. Just resolved this one now. Can you try again?
>
> (You may need to visit https://id.fedoraproject.org/logout first.)
>
Yes, it's working fine now. Thanks.
Att.
--
Rafael Fonseca
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
Pierre-Yves Chibon wrote: > On Thursday, a new version of Bodhi was deployed that enabled Bodhi to > gate updates based on test results. You may notice a "Test Gating > Status" message in the right have side of the page. ... > There are three tests that must pass in order for updates to go to stable: > > 0. dist.depcheck - to make sure the update's dependencies are available. > 1. dist.abicheck - to make sure the update's ABI remains stable in a >given Fedora release. ... > Finally, if it turns out you need to push an update through despite of the > test results, you can do so using waiver-cli (dnf install waiverdb-cli). > We are working on integrating this into Bodhi itself, making this easier. I think it unwise to make item 1 a mandatory item at this point. I'd argue a large number of packages do not provide public api/abi that's worth worrying about in this regard. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, Jan 23, 2018 at 06:35:45PM +0100, Rafael dos Santos wrote:
> I get this error after clicking the authorization link:
>
> [16450:16491:0123/182437.407698:ERROR:browser_gpu_channel_host_factory.cc(120)]
> Failed to launch GPU process.
> Created new window in existing browser session.
> 127.0.0.1 - - [23/Jan/2018 18:24:37] "GET
> /?error_description=Unknown+client+ID&error=unauthorized_client HTTP/1.1"
> 200 47
> Traceback (most recent call last):
> File "/usr/bin/waiverdb-cli", line 11, in
> load_entry_point('waiverdb==0.4.0', 'console_scripts', 'waiverdb-cli')()
> File "/usr/lib/python2.7/site-packages/click/core.py", line 722, in
> __call__
> return self.main(*args, **kwargs)
> File "/usr/lib/python2.7/site-packages/click/core.py", line 697, in main
> rv = self.invoke(ctx)
> File "/usr/lib/python2.7/site-packages/click/core.py", line 895, in invoke
> return ctx.invoke(self.callback, **ctx.params)
> File "/usr/lib/python2.7/site-packages/click/core.py", line 535, in invoke
> return callback(*args, **kwargs)
> File "/usr/lib/python2.7/site-packages/waiverdb/cli.py", line 102, in cli
> if not resp.ok:
> AttributeError: 'NoneType' object has no attribute 'ok'
ACK. Just resolved this one now. Can you try again?
(You may need to visit https://id.fedoraproject.org/logout first.)
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, Jan 23, 2018 at 06:37:56PM +0100, Rafael dos Santos wrote: > On 23 January 2018 at 18:20, Ralph Bean wrote: > > I've removed the abicheck requirement from the greenwave policies for > > now until we know more: > > https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id= > > 465f155d140a9fbe34f0f51dbfc2137b2900a6f8 > > > > Do we have to do anything to proceed? I still seem not able to push my > update to stable. Hopefully the Bodhi maintainers can have a look; Bodhi may be caching the decision here. IIRC, there's a cronjob to synchronize on the Bodhi side. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, Jan 23, 2018 at 08:13:02AM -0500, Matthew Miller wrote: > On Tue, Jan 23, 2018 at 10:32:49AM +0100, Pierre-Yves Chibon wrote: > > We just sent an announcement about this, sorry for being late on this. > > > > Basically, you can "waive" test results using waiverdb-cli (dnf install > > waiverdb-cli) which will allow the update to go through despite of the > > failing > > test. > > We're working on putting this into bodhi itself for easier use. > > Can someone who knows what they're talking about put this into > https://fedoraproject.org/wiki/Package_update_HOWTO?rd=PackageMaintainers/UpdatingPackageHowTo#Handling_feedback_from_automated_tests I added some more detail just now. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, Jan 23, 2018 at 05:18:42PM +0100, Adam Williamson wrote: > On Tue, 2018-01-23 at 08:42 -0700, Jerry James wrote: > > Where are the instructions? Why is informing packagers, the group > > most affected by this change, an afterthought? We should have been > > told about all of this, in detail, prior to the thing being turned on, > > *well* before it was turned on. > > So, my answer to this is second-hand - apologies if any of it is wrong, > and the folks involved will no doubt correct me. But as I understand > it, I think they weren't really expecting the tests that were turned on > to have false positives; the tests that were chosen were intended to be > ones that wouldn't cause this kind of problem, so there'd be more time > to get all the waiverdb integrations in place. I don't think they > actually anticipated that false positives would happen and people would > need to use waiverdb-cli like this, which is why instructions for it > weren't part of the plan. I'm sure no-one intended to cause disruption > and inconvenience, and we're sorry about it. I'll try to ask the > relevant folks if perhaps we should stop gating on the abidiff test for > now as a short-term measure, or something like that. The problem for the OCaml packages is missing tests or tests that haven't been run: https://bodhi.fedoraproject.org/updates/FEDORA-2018-932548462e https://bodhi.fedoraproject.org/updates/FEDORA-2018-ecd3541af9 BTW these both really need to be pushed as soon as possible because they fix a license violation. 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: -z defs linker flag activated in Fedora rawhide
On Tue, Jan 23, 2018 at 05:56:47PM +, Jonathan Wakely wrote: > On 23/01/18 15:38 +0100, Florian Weimer wrote: > > We could deactivate -z defs for F28 and reactivate it after the branch > > for F29, giving packagers more time to fix issues. > > I think that might be a good idea (given how late in the F28 process > we are) but for many packages it will just mean we have the same > problem at the next mass rebuild. > > Lots of packages don't get rebuilt between releases, so the > maintainers won't see any failure for F29 after -z defs becomes the > default again, so they won't fix anything. > > Every package known to have problems now should get added to koschei. What needs to be done for this ? I see my package "libvirt" present in its UI https://apps.fedoraproject.org/koschei/package/libvirt but it says "Package is currently ineligible for scheduling due to following reasons: Package is not tracked Package dependencies were not resolved yet" but there's no info about what these reasons really mean, nor how I would go about resolving them. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: -z defs linker flag activated in Fedora rawhide
On 23/01/18 15:38 +0100, Florian Weimer wrote: We could deactivate -z defs for F28 and reactivate it after the branch for F29, giving packagers more time to fix issues. I think that might be a good idea (given how late in the F28 process we are) but for many packages it will just mean we have the same problem at the next mass rebuild. Lots of packages don't get rebuilt between releases, so the maintainers won't see any failure for F29 after -z defs becomes the default again, so they won't fix anything. Every package known to have problems now should get added to koschei. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On 01/23/2018 01:28 AM, Pierre-Yves Chibon wrote: > There are three tests that must pass in order for updates to go to stable: > > 0. dist.depcheck - to make sure the update's dependencies are available. > 1. dist.abicheck - to make sure the update's ABI remains stable in a >given Fedora release. > 2. AtomicCI pipeline - packages that are part of the Atomic Host *and* include >in their dist-git tests, must have these tests passed in the AtomicCI > pipeline > > This last requirement only concern packages that are in the Atomic Host while > the first two is enforced for all packages. In my rust+cargo updates, I'm getting "1 of 4 required tests not found". f27: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d5eb234853 f26: https://bodhi.fedoraproject.org/updates/FEDORA-2018-ae3b642c47 It looks like it ran lots of tests for cargo, but only one on rust. What can I do to resolve this? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On 23 January 2018 at 18:20, Ralph Bean wrote: I've removed the abicheck requirement from the greenwave policies for > now until we know more: > https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id= > 465f155d140a9fbe34f0f51dbfc2137b2900a6f8 > Do we have to do anything to proceed? I still seem not able to push my update to stable. Att. -- Rafael Fonseca ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
I get this error after clicking the authorization link:
[16450:16491:0123/182437.407698:ERROR:browser_gpu_channel_host_factory.cc(120)]
Failed to launch GPU process.
Created new window in existing browser session.
127.0.0.1 - - [23/Jan/2018 18:24:37] "GET
/?error_description=Unknown+client+ID&error=unauthorized_client HTTP/1.1"
200 47
Traceback (most recent call last):
File "/usr/bin/waiverdb-cli", line 11, in
load_entry_point('waiverdb==0.4.0', 'console_scripts', 'waiverdb-cli')()
File "/usr/lib/python2.7/site-packages/click/core.py", line 722, in
__call__
return self.main(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/usr/lib/python2.7/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python2.7/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/waiverdb/cli.py", line 102, in cli
if not resp.ok:
AttributeError: 'NoneType' object has no attribute 'ok'
Att.
--
Rafael Fonseca
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, Jan 23, 2018 at 02:21:02PM +0100, Adam Williamson wrote: > On Tue, 2018-01-23 at 10:32 +0100, Pierre-Yves Chibon wrote: > > > > We just sent an announcement about this, sorry for being late on this. > > > > Basically, you can "waive" test results using waiverdb-cli (dnf install > > waiverdb-cli) which will allow the update to go through despite of the > > failing > > test. > > We're working on putting this into bodhi itself for easier use. > > Note, just waiving this kind of failure one-by-one doesn't seem like > the proper fix for this to me. Patrick told me yesterday that he'd seen > or been told about a different (I think) but similar case; I think > there may be kind of a generic issue with the ABI diff test checking > the ABI of shared objects that aren't actually 'public' in any > meaningful way. We should look at that as a generic issue. I'm sending > a mail to qa-devel@ to flag this up to the Taskotron devs. We could > consider dropping this test from the gating list again until this is > looked into... I've removed the abicheck requirement from the greenwave policies for now until we know more: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=465f155d140a9fbe34f0f51dbfc2137b2900a6f8 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, Jan 23, 2018 at 10:32:49AM +0100, Pierre-Yves Chibon wrote: > On Mon, Jan 22, 2018 at 01:57:34PM -0700, Jerry James wrote: > > Here's something I didn't expect from the new ABI gate. Which, before > > I go further, I think will be a great idea nearly all of the time. I > > think avoiding unintentional ABI breaks in stable releases is a worthy > > goal. > > > > But ... I maintain a package called gap. It provides what amounts to > > a scripting language for doing certain types of math. It comes with a > > bunch of addon packages that provide specific mathematical > > capabilities. Most of them are written solely in the scripting > > language, but a few have to interface with external libraries. When > > that is required, these packages build a small internal-only shared > > object to act as the glue between the external library and the > > scripting language. > > > > I've got a pending update for one of these packages that fixes some > > bugs. It has been caught by the ABI gate: > > https://bodhi.fedoraproject.org/updates/FEDORA-2018-e45a7bb9a7 > > > > There is no danger in pushing this to stable, since the only consumer > > of the changed ABI is inside the same package. Now what do I do? Are > > ABI changes completely disallowed in all circumstances? Is there a > > button somewhere that says, "I am aware of the danger of pushing this > > to stable and I have verified that nothing will break in this case"? > > We just sent an announcement about this, sorry for being late on this. > > Basically, you can "waive" test results using waiverdb-cli (dnf install > waiverdb-cli) which will allow the update to go through despite of the failing > test. > We're working on putting this into bodhi itself for easier use. FYI, here's the change for the Bodhi UI: https://github.com/fedora-infra/bodhi/pull/2095 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging
- Mail original - De: "nicolas mailhot" > Now that the non-Go part in redhat-rpm-macros is merged in devel I'll try to > do a clean PR on go-srpm-macros. > Then once Jan or Jakub accepts it it will be possible to play with the > automation in devel and I'll be able to share my specs somewhere (not that > the work is finished, but some parts *are* finished and I'd rather have the > people who > use those packages to review my conversions rather than redo part of them > without sharing existing work) And the PR is done and sent: https://src.fedoraproject.org/rpms/go-srpm-macros/pull-request/1 Now I only need to revisit https://fedoraproject.org/wiki/More_Go_packaging and enhance it with the packaging patterns that emerged after applying the proposal to the last few hundreds of Go spec files. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Fedora-packaging] Re: Re: Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging
- Mail original - De: "Neal Gompa" > For snipping, use "[...]" notation to indicate skipped stuff. It's > hard to tell otherwise. Ok, that was easy to fix :) -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Looking for contact with Daniel Veillard libxml2 maintainer
On Tue, Jan 23, 2018 at 10:45 AM, Tomasz Kłoczko wrote: Strange only is that looks like this bug already is known more than year! Looks like two years... I followed the chain of links in the Red Hat bugs, which claim this is already reported as https://bugzilla.gnome.org/show_bug.cgi?id=762100 and fixed by https://git.gnome.org/browse/libxml2/commit/?id=bdd66182ef53fe1f7209ab6535fda56366bd7ac9. If that's correct (a big "if" ;) then our libxml2 package should not be vulnerable. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposed Fedora packaging guideline: More Go packaging
I wish this message wasn't crossposted everywhere, but I don't want to lose any discussion by trimming the CC list. Sorry if replies generate bounces for some. > "nm" == nicolas mailhot writes: nm> And the forge macros are now available since nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to upstream nm> renaming the file). Heartfelt thanks to Jason Tibbitts ! Please don't forget to let me know when it's time to start thinking about pushing this down to F27. And maybe F26. And as far as I can tell it should work with only minor modification in EPEL7 (via epel-rpm-macros). I don't know about EPEL6, but we really should look at it given some of the other discussions about specfile compatibility. Some packagers wouldn't ever use it if it doesn't work everywhere. Finally, we should also talk about whether there is any integration or automation possible between fedpkg and specfiles configured with these macros. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Looking for contact with Daniel Veillard libxml2 maintainer
On 23 January 2018 at 16:24, Tomasz Kłoczko wrote: > On 23 January 2018 at 15:59, wrote: > [..] >> That said... has the patch been proposed for inclusion upstream? It looks >> like Nick Wellnhofer is taking care of libxml2 upstream these days, so it >> shouldn't need to wait for Daniel. I see you only included a link to a >> Chromium bug report with the patch; IMO that's not good enough, because we >> don't know if Chromium has reported the issue upstream or not. The libxml2 >> issue tracker is at >> https://bugzilla.gnome.org/enter_bug.cgi?product=libxml2. > > Everything at the moment is only in the ticket: > https://bugzilla.redhat.com/show_bug.cgi?id=1529121 > As I have gnome bugzilla account as well will ASAP try create necessary > ticket. Just found a bit more in RH bugzilla searching for "CVE-2016-9597" https://bugzilla.redhat.com/show_bug.cgi?id=1408305 and more is here: https://access.redhat.com/errata/RHSA-2016:2957 Looks like at the moment this bug is affecting at least jboss. Because this patch has been added to chrome source tree it is quite possible that it affects generally gnome desktop as well. Strange only is that looks like this bug already is known more than year! kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc
On Tue, 2018-01-23 at 08:00 +0100, Florian Weimer wrote: > On 01/22/2018 10:15 PM, Adam Jackson wrote: > > On Mon, 2018-01-22 at 19:19 +0100, Florian Weimer wrote: > > > Redeclarations in system headers are expected. Do you compile with > > > -Wsystem-headers? Or do you something else which is unusual, such as > > > running the preprocessor separately? > > > > Not that I'm aware of. The generated cc line is: > > > > ninja: Entering directory `build' > > [1/17] ccache cc -Ios/libxserver_os@sta -Ios -I../os -Ixfixes -I../xfixes > > ccache runs the preprocessor separately. 8-) Hah! Of course it would. Thanks for the explanation. - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Redirects for wiki pages moved to docs [was Re: ABI gate: internal-only shared object]
(Resending with correct docs list cc. Sorry about that.) On Tue, Jan 23, 2018 at 11:30:46AM -0500, Matthew Miller wrote: > On Tue, Jan 23, 2018 at 03:21:56PM +0100, Adam Williamson wrote: > > It's a bit off-topic, but...when this happens, what do we do about > > links? There are probably many links to this page. This applies to > > anything being 'converted' from the wiki to docs, I guess...can we make > > wiki URLs redirect to a docs page after conversion? Or do we have to > > make the wiki page just show a link to the docs page? > > I've just been making stubs like > https://fedoraproject.org/wiki/Council, which isn't ideal. > > Mediawiki has some extensions which allow external redirects, but I > don't think we can safely enable anything which allows *arbitrary* > redirects. > > We could either look at modifying the ExternalRedirecct > extension to be something like DocsRedirect and hard-code the > https://docs. part, or we could follow this suggestion > https://stackoverflow.com/a/36634532/479426, which is to create a > "MovedToDocs" namespace and allow the extension there, and then give > a restricted set of people permission to move things into that space. > > > > -- > Matthew Miller > > Fedora Project Leader -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On 23/01/18 16:18, Adam Williamson wrote: On Tue, 2018-01-23 at 08:42 -0700, Jerry James wrote: Where are the instructions? Why is informing packagers, the group most affected by this change, an afterthought? We should have been told about all of this, in detail, prior to the thing being turned on, *well* before it was turned on. So, my answer to this is second-hand - apologies if any of it is wrong, and the folks involved will no doubt correct me. But as I understand it, I think they weren't really expecting the tests that were turned on to have false positives; the tests that were chosen were intended to be ones that wouldn't cause this kind of problem, so there'd be more time to get all the waiverdb integrations in place. I don't think they actually anticipated that false positives would happen and people would need to use waiverdb-cli like this, which is why instructions for it weren't part of the plan. I'm sure no-one intended to cause disruption and inconvenience, and we're sorry about it. I'll try to ask the relevant folks if perhaps we should stop gating on the abidiff test for now as a short-term measure, or something like that. There was one that came up on IRC yesterday that had failed abidiff entirely because of added functions as far as I could see. I don't know if that counts as a false positive or not because I don't know what the design goals are - added functions should mean it's not going to break any existing programs but new programs built against it might not work against old versions of the library. 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
Re: [Bug 1529276] New: findbugs-contrib-7.2.0.sb is available
On Sat, Jan 13, 2018 at 11:50:44PM +0100, Michael Schwendt wrote: > On Fri, 12 Jan 2018 16:13:24 +0100, Pierre-Yves Chibon wrote: > > > I believe the script runs at least daily so if you see something wrong then > > do > > report it :) > > Here's a recently opened ticket about package "aide": > > Date: Fri, 12 Jan 2018 11:17:42 + > https://bugzilla.redhat.com/show_bug.cgi?id=1533845 > > I should not be in the default Cc list for that package. > Whatever data bugzilla had used in this case must be from a few > years ago. Looking back into this after a while (sorry about that), it looks like you're listed to as watching tickets and commits on dist-git: https://src.fedoraproject.org/api/0/rpms/aide/watchers Which is odd since pkgdb seems to not have you there: https://admin.fedoraproject.org/pkgdb/package/rpms/aide/ So I'd recommend you go to the project on dist-git and reset your watch status on the eye icon at the top right of the page. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Redirects for wiki pages moved to docs [was Re: ABI gate: internal-only shared object]
On Tue, Jan 23, 2018 at 03:21:56PM +0100, Adam Williamson wrote: > It's a bit off-topic, but...when this happens, what do we do about > links? There are probably many links to this page. This applies to > anything being 'converted' from the wiki to docs, I guess...can we make > wiki URLs redirect to a docs page after conversion? Or do we have to > make the wiki page just show a link to the docs page? I've just been making stubs like https://fedoraproject.org/wiki/Council, which isn't ideal. Mediawiki has some extensions which allow external redirects, but I don't think we can safely enable anything which allows *arbitrary* redirects. We could either look at modifying the ExternalRedirecct extension to be something like DocsRedirect and hard-code the https://docs. part, or we could follow this suggestion https://stackoverflow.com/a/36634532/479426, which is to create a "MovedToDocs" namespace and allow the extension there, and then give a restricted set of people permission to move things into that space. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Looking for contact with Daniel Veillard libxml2 maintainer
On 23 January 2018 at 15:59, wrote: [..] > That said... has the patch been proposed for inclusion upstream? It looks > like Nick Wellnhofer is taking care of libxml2 upstream these days, so it > shouldn't need to wait for Daniel. I see you only included a link to a > Chromium bug report with the patch; IMO that's not good enough, because we > don't know if Chromium has reported the issue upstream or not. The libxml2 > issue tracker is at > https://bugzilla.gnome.org/enter_bug.cgi?product=libxml2. Everything at the moment is only in the ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1529121 As I have gnome bugzilla account as well will ASAP try create necessary ticket. CVE patch is in partial pull request patch and can be cherry picket using git (and resolve patch conflict by delete all libxml2.spec changes) https://src.fedoraproject.org/fork/kloczek/rpms/libxml2/c/eb936f5b802a45441abab45fa6f1707bd0575651 Or even c&p or download from: https://src.fedoraproject.org/fork/kloczek/rpms/libxml2/raw/eb936f5b802a45441abab45fa6f1707bd0575651 and added manually to existing latest libxml2.spec. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, 2018-01-23 at 08:42 -0700, Jerry James wrote: > > There are no instructions on how to use it on this wiki page. Okay, > we'll try using --help: > > $ waiverdb-cli --help > Usage: waiverdb-cli [OPTIONS] > > Creates new waivers against test results. > > Examples: > > waiverdb-cli -r 123 -r 456 -p "fedora-26" -c "It's dead!" > > Options: > -C, --config-file PATH Specify a config file to use > -r, --result-id INTEGER Specify one or more results to be waived > -p, --product-version TEXT Specify one of PDC's product version > identifiers. > --waived / --no-waived Whether or not the result is waived > -c, --comment TEXT A comment explaining why the result is waived > -h, --help Show this message and exit. > > > Ookaay, so what is a result-id and how do I figure out which > one I need to supply for my particular case? It's how resultsdb identifies a single specific result. Each result in resultsdb has one, and they're unique. However, I see an obvious problem here: I can't see any easy way to figure out the result ID of the failure from the Bodhi web UI. The URL you get taken to when you click on the test result in Bodhi doesn't include it, so far as I can see. You *can* actually find the failed test quite 'easily' from the resultsdb web UI, but you have to know how to do it: go to the search page - https://taskotron.fedoraproject.org/resultsdb/results - and enter the package NVR (gap-pkg-io-4.5.1-1.fc27) as the 'item', and dist.abicheck as the 'testcase', then search, and you'll find it. Then click 'details' and you can see the ID is 18913262. But that's obviously not an ideal workflow! As Pierre said, they're working on hooking this all up from the Bodhi web UI so waiving will be a much easier process. > I can guess what a > product-version is, but why is it in a different format from every > other Fedora tool that takes such a thing? Because that's the form PDC uses; waiverdb works with PDC, and PDC chose its format a while ago, so that's kind of plumbed in now. > How do I point this tool > at the update of mine that is currently being blocked? At least AIUI, you don't actually have to: all that matching logic is performed by the various systems involved. Basically, Bodhi asks Greenwave if the update is good to go; Greenwave asks ResultsDB for tests associated with the update, and asks WaiverDB for waivers associated with those tests. So its answer to Bodhi will take the waiver into account. All you have to do is submit the waiver. > Where are the instructions? Why is informing packagers, the group > most affected by this change, an afterthought? We should have been > told about all of this, in detail, prior to the thing being turned on, > *well* before it was turned on. So, my answer to this is second-hand - apologies if any of it is wrong, and the folks involved will no doubt correct me. But as I understand it, I think they weren't really expecting the tests that were turned on to have false positives; the tests that were chosen were intended to be ones that wouldn't cause this kind of problem, so there'd be more time to get all the waiverdb integrations in place. I don't think they actually anticipated that false positives would happen and people would need to use waiverdb-cli like this, which is why instructions for it weren't part of the plan. I'm sure no-one intended to cause disruption and inconvenience, and we're sorry about it. I'll try to ask the relevant folks if perhaps we should stop gating on the abidiff test for now as a short-term measure, or something like that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Looking for contact with Daniel Veillard libxml2 maintainer
On Tue, Jan 23, 2018 at 9:07 AM, Tomasz Kłoczko wrote: If it will be no new actions to the end of this week I'm going to raise FESCo ticket to takeover at least libxml2. Yes, libxml2 is security-critical; we can't wait this long to apply security patches. The Fedora package maintainer needs to be able to respond in a timely manner. Thanks for working on this, Tomasz. That said... has the patch been proposed for inclusion upstream? It looks like Nick Wellnhofer is taking care of libxml2 upstream these days, so it shouldn't need to wait for Daniel. I see you only included a link to a Chromium bug report with the patch; IMO that's not good enough, because we don't know if Chromium has reported the issue upstream or not. The libxml2 issue tracker is at https://bugzilla.gnome.org/enter_bug.cgi?product=libxml2. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, Jan 23, 2018 at 2:28 AM, Pierre-Yves Chibon wrote: > Finally, if it turns out you need to push an update through despite of the > test > results, you can do so using waiver-cli (dnf install waiverdb-cli). We are > working on integrating this into Bodhi itself, making this easier. Good! I need this. So let's apply it to my update. H, there is no man page in the waiverdb-cli package. There are no instructions on how to use it in this email. > We have started a wiki page to store all of this information and that we will > keep up to date as improvements are done or for any frequent questions coming > up: > > https://fedoraproject.org/wiki/CI/gating_updates There are no instructions on how to use it on this wiki page. Okay, we'll try using --help: $ waiverdb-cli --help Usage: waiverdb-cli [OPTIONS] Creates new waivers against test results. Examples: waiverdb-cli -r 123 -r 456 -p "fedora-26" -c "It's dead!" Options: -C, --config-file PATH Specify a config file to use -r, --result-id INTEGER Specify one or more results to be waived -p, --product-version TEXT Specify one of PDC's product version identifiers. --waived / --no-waived Whether or not the result is waived -c, --comment TEXT A comment explaining why the result is waived -h, --help Show this message and exit. Ookaay, so what is a result-id and how do I figure out which one I need to supply for my particular case? I can guess what a product-version is, but why is it in a different format from every other Fedora tool that takes such a thing? How do I point this tool at the update of mine that is currently being blocked? Where are the instructions? Why is informing packagers, the group most affected by this change, an afterthought? We should have been told about all of this, in detail, prior to the thing being turned on, *well* before it was turned on. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Self-Introduction Christian Glombek (lorbus) / NEEDSPONSOR / NEEDREVIEWs / Let's Meet @ DevConf or FOSDEM!
Hello World! My name is Christian Glombek (or simply Chris :) and I'd like to join the Fedora Packagers Group. I'm currently a student of Electrical Engineering and Business Management at RWTH University in Aachen, Germany. My FAS and IRC handle is `lorbus` and on GitHub and Twitter I'm `LorbusChris`. I've been using Fedora for two or so years on my daily drivers, very much to my satisfaction. Fedora's focus on modern concepts, especially container technology, intrigues me. Its community to me has always seemed open, friendly, diverse and knowledgeable. I also feel that Fedora's sponsor Red Hat has established a symbiotic relationship with this community, transparently supporting a quite remarkable and rightfully successful business model. I feel passionate about Open Source Technology and would like to participate! Over the past few months I've been feeding my interests in some corners of the extended Fedora universe, mainly tinkering with RPM and Ansible Playbook Bundle (APB) packaging and also trying out custom Atomic/OSTree builds (love Atomic Workstation!). RPMs: NEEDSPONSOR I want to get some packages into Fedora proper and I need a sponsor for that! I'd also hugely appreciate (unofficial) reviews or any other feedback for the following packages: coturn-rpm: NEEDREVIEW BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1491492 COPR: https://copr.fedorainfracloud.org/coprs/lorbus/coturn/ Repo: https://github.com/LorbusChris/coturn-rpm libreoffice-online-rpm: NEEDREVIEW (later, WIP) BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1494915 COPR: https://copr.fedorainfracloud.org/coprs/lorbus/libreoffice-online/ Repo: https://github.com/LorbusChris/libreoffice-online-rpm Note: The frontend part of libreoffice-online, loleaflet, uses `npm install` during build (versioned with a npm-shrinkwrap file). From what I've read about packaging nodejs modules, I'll probably have to manually download and add all module sources to the rpm. WIP. rspamd-rpm: NEEDREVIEW (later, WIP) BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1494914 COPR: https://copr.fedorainfracloud.org/coprs/lorbus/rspamd/ Repo: https://github.com/LorbusChris/rspamd-rpm Note: I'll have to gather some more info about bundled softwares, possibly split out some existing dep packages. ragel-rpm / colm-rpm: I also did some work updating the already-existing Ragel (dep of Rspamd) and Colm (dep of Ragel) rpms and was consequently asked by current repo maintainer Jason Taylor (jtaylor) to take over the position, which I'll gladly do once I've found a sponsor and get the privilege of joining the packagers' group! I'd like to try out Modularity packaging for Ragel as it has two release streams, stable and development, of which only the latter is in Fedora. (I made a ragel-compat rpm for the stable release stream, which can be found on COPR, but I believe Modularity's arbitrary branching would be a perfect fit here!) COPR ragel-compat: https://copr.fedorainfracloud.org/coprs/lorbus/ragel-compat/ APBs: I also like the idea of the Kubernetes Service Catalog, in conjunction with the Ansible Service Broker (and Ansible in general) and so I did some tinkering with Ansible Playbook Bundles, the packaging format for the Ansible Broker: awx-apb: Repo: https://github.com/LorbusChris/awx-apb Note: APB to broker (provision/deprovision) Ansible AWX. Can also be used as an alternative installer for AWX deployment on OpenShift. openshift-acme-installer: Repo: https://github.com/LorbusChris/openshift-acme-installer Note: Installer for https://github.com/tnozicka/openshift-acme Non-standard privilged (cluster-admin) APB, can be used as installer, not currently for brokering. Eventually, I'd like to see FreeIPA, Dovecot, Postfix, Rspamd, Clamd, NextCloud, LibreOffice Online, Prosody and Coturn all packaged for Fedora as RPM and Docker and for K8s Service Catalog as APB for use in a little pet project of mine: https://github.com/contor-cloud/contor (WIP) Expect to see me around on the IRC, too! I'll be saying hello in the relevant channels in the coming days. If you have any questions or maybe have a task for me at hand, please let me know! Attending Conferences In December I met up with Fedora Ambassador Till Maas (till) for tea here in Aachen and was given answers to lots of my questions regarding Fedora. Thanks again, Till! He also encouraged me to attend conferences, which is why I will be at: - DevConf.cz, Brno, Jan 26-28, that's this Weekend! - CentOS Dojo, Brussels, Feb 2 - FOSDEM, Brussels, Feb 3 - Config Management Camp, Gent, Feb 5-7 I hope to meet some members of the community there in person! Please feel free to ping me if you're there! :) I'm looking forward to participating and contributing here! Best regards Christian Glombek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Starting Boost 1.66.0 rebuilds in f28-boost side tag
As happens for most releases, I'm updating Boost in rawhide and rebuilding the affected packages in a side tag (f28-boost). https://fedoraproject.org/wiki/Changes/F28Boost166 If you maintain a package that depends on Boost please coordinate any updates with me, so that any changes you make in the main f28 target don't invalidate the rebuilds I'm doing in f28-boost. I've already identified about a dozen packages that are FTBFS in rawhide, but only two are due to the Boost update (dssp and domoticz). The rest are due to package bugs that cause linker errors now the rpm build flags default to -z defs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposed Fedora packaging guideline: More Go packaging
On 12/17/2017 01:11 AM, nicolas.mail...@laposte.net wrote: Hi, I am proposing for inclusion a set of rpm technical files aimed at automating the packaging of forge-hosted projects. - Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging - https://pagure.io/packaging-committee/issue/734 - go-srpm-macros RFE with the technical files: https://bugzilla.redhat.com/show_bug.cgi?id=1526721 Hi, This looks pretty cool! One thing I notice in the limitations section of your draft is a lot of "we can't do XXX due to lack of release discipline..." Do you have any recommendations for Go programmers on how to structure their software so that it is easy to package? Thanks, -Mat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Looking for contact with Daniel Veillard libxml2 maintainer
On 16 January 2018 at 18:01, Tomasz Kłoczko wrote: [..] > >> https://bugzilla.redhat.com/show_bug.cgi?id=1529121 > > > > I think you should find a new maintainer for libxml2, and libxslt, and > > xmlsec1 > > because right now I have little time, and since Fedora changes the rules for > > spec file all the time, they are not interoperable with RHEL/CentOS so the > > net benefit of maintaining them becomes very low. > > I would be happy start maintaining those packages and/or any other > Fedora packages which you own as admin. > You can give the project by login to FAS and (in case libxml2) go to > https://src.fedoraproject.org/rpms/libxml2/settings -> on the bottom > of the page is "Give the project" and enter "kloczek" in line below, > and press red button below to finalize transfer. I've been patiently waiting week on some actions or replies. No other replies (publicly or privately) or actions have been taken in meantime. Daniel if you really have no time to maintain your packages you should reassign them to other active packager. I've offered that I can take your packages however if you are thinking that you have other/better candidates just please reassign your packages to such person. Please do something .. libxml2 has known CVE so at least please do something about only this package. Pull request is now one month old. If you don't like my other changes just please at least fix CVE. If it will be no new actions to the end of this week I'm going to raise FESCo ticket to takeover at least libxml2. I've been already waiting longer than it is described on: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Outline kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Fedora-packaging] Re: Re: Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging
On Tue, Jan 23, 2018 at 9:40 AM, wrote: > >> - Mail original - >> De: "Neal Gompa" > >>> I'm curious, what are you missing in the preamble ? As far as I can see >>> it's all there (even though some values >>> set to variables %gometa precomputes). I had it's right autogenerated some >>> parts of it in the past but it's all >>> converted to variable use now to avoid packager surprise and permit >>> customization. > >> Actually, this is fine with me. This is what disturbed me a bit: >> https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_examples > > Ah, yes the examples snip the lines that do not need specific changes for > readability > Is the … not clear enough? > I fear that putting a full preamble would be even more confusing for some > readers. Though if people disagree, I'l try to find some time to add the > skipped lines back in > For snipping, use "[...]" notation to indicate skipped stuff. It's hard to tell otherwise. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: [Fedora-packaging] Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging
> - Mail original - > De: "Neal Gompa" >> I'm curious, what are you missing in the preamble ? As far as I can see it's >> all there (even though some values >> set to variables %gometa precomputes). I had it's right autogenerated some >> parts of it in the past but it's all >> converted to variable use now to avoid packager surprise and permit >> customization. > Actually, this is fine with me. This is what disturbed me a bit: > https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_examples Ah, yes the examples snip the lines that do not need specific changes for readability Is the … not clear enough? I fear that putting a full preamble would be even more confusing for some readers. Though if people disagree, I'l try to find some time to add the skipped lines back in -- Nicolas Mailhot -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: -z defs linker flag activated in Fedora rawhide
On 01/23/2018 12:26 PM, Mamoru TASAKA wrote: Florian Weimer wrote on 01/23/2018 12:24 AM: In some cases (such as when a DSO is loaded as a plugin and is expected to bind to symbols in the main executable), undefined symbols are expected. In this case, you can add %undefine _strict_symbol_defs_build to the RPM spec file to disable these strict checks. So this seems to affect lots of packages containing /usr/lib64/foo/libbar.so. At least my packages - cairo-dock It's not clear whether this isn't rather a package bug. Many symbols could come from -lgldi as well, but some of them are defined by /usr/bin/cairo-dock as well. However, that program has a DT_NEEDED entry for libgldi.so.3, so it is unclear what is going on. Have you tried adding the missing -l arguments? - cairo-dock-plug-ins (not checked) - gnome-commander This has a plugin-style reference for main_win_widget (which is only defined in /usr/libexec/gnome-commander/gnome-commander), but failures further down are to a missing -lgcmd. Definitely a mixed bag. failed to build due to this, and at least - dia Looks like a missing -lglib-2.0, so it's a package bug. - sssd Looks like a package bug, probably a missing -lsss_util. (Although it is not entirely clear which sssd shared object contains the canonical definition of each function.) - ModemManager This is a true plug-in case, so it needs to avoid to build with -z defs (which will obscure the missing -lglib-2.0, which should nevertheless be added). - pidgin Looks like a missing -lpurple -lpthread -lglib-2.0, probably more. (/usr/sbin/bitlbee defines some purple_* symbols, but I don't know if any of the compiled DSOs are in fact plug-ins for that program. If not, it should be possible to get the whole thing to link with -z defs.) So the majority of these issues are package bugs. This is not entirely what I expected—in an ideal world, the impact would have been restricted to true plug-ins. Some of the existing linking issues aren't entirely harmless and can cause problems today or further down the road (because the dependency information on various layers is incorrect). We could deactivate -z defs for F28 and reactivate it after the branch for F29, giving packagers more time to fix issues. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging
- Mail original - De: "Fabio Valentini" > So, if I understand correctly, both the forge stuff and the new macros for > go packaging are completely opt-in? > If that's correct, this looks like the best solution to me - as old > packages can then be converted one at a time (which I am looking forward to > doing for my go packages, btw.). It is fully opt-in. You can also use some parts and ignore others (though it's probably more complex than just using all of it unless you understand the new parts really well). However I should warn that packaging "new-style" something is likely to force conversion to "new-style" at least some of its deps."Old-style" manual declaration of provides often forgets elements and autodeps have no mercy on missing provides. But, some of the "new-style" specs I did depend on existing Fedora packages I didn't have to touch. Now that the non-Go part in redhat-rpm-macros is merged in devel I'll try to do a clean PR on go-srpm-macros. Then once Jan or Jakub accepts it it will be possible to play with the automation in devel and I'll be able to share my specs somewhere (not that the work is finished, but some parts *are* finished and I'd rather have the people who use those packages to review my conversions rather than redo part of them without sharing existing work) Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, 2018-01-23 at 08:13 -0500, Matthew Miller wrote: > On Tue, Jan 23, 2018 at 10:32:49AM +0100, Pierre-Yves Chibon wrote: > > We just sent an announcement about this, sorry for being late on this. > > > > Basically, you can "waive" test results using waiverdb-cli (dnf install > > waiverdb-cli) which will allow the update to go through despite of the > > failing > > test. > > We're working on putting this into bodhi itself for easier use. > > Can someone who knows what they're talking about put this into > https://fedoraproject.org/wiki/Package_update_HOWTO?rd=PackageMaintainers/UpdatingPackageHowTo#Handling_feedback_from_automated_tests Note: I've just updated the page somewhat, mainly to bring it into line with the current reality regarding what automated tests are run and how the results are displayed. I did introduce a little stub sentence about waiverdb-cli, but it'd still be great if someone who knows the exact syntax for waiving a particular result could extend that. > (Also, that document is a great candidate for conversion to the new > docs system. Just sayin'.) It's a bit off-topic, but...when this happens, what do we do about links? There are probably many links to this page. This applies to anything being 'converted' from the wiki to docs, I guess...can we make wiki URLs redirect to a docs page after conversion? Or do we have to make the wiki page just show a link to the docs page? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unannounced SONAME bump in tinyxml2
On Tue, Jan 23, 2018 at 2:48 PM, Igor Gnatenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > https://src.fedoraproject.org/rpms/tinyxml2/c/3600750a8f1b0eaa6cab346496fd75a07 > ea749cb This was announced to all package owners depending on tinyxml2 right after the build succeed on f28 (unless I missed any). Most rebuilds are already done. > - -- > - -Igor Gnatenko > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpnPSEACgkQaVcUvRu8 > X0zgYBAAqfV6lP/OHdB/tsCsojIw/xjjSt+1jhQzuBO6Hlk22vUDkXeeueJG2IQF > ej/eXR8/+GYOrV73vfH4z8XTWzbQuPWhnXak8qnJ052riwkr1lI1kLsD+IKi82kt > cQDNGJ6BwMydIzUVYpF9XzCVMh8NdKtrS2VIBz4NjJk9jLhqVPY1kfm0qakTdpSI > YajRfp4dlSwMC/LvUriY5I3aOIpogKKBog+VDxEUBhE9MI31af5ZX81RYJRA+lrT > RXYxZHUc5b4xJ1vaUAziOYOZVfq2pE/rr+8aKtL4m+StKc09aHyYdF8p1zZAycpK > mKdKs9mkR16E+Kjn3JriMtMH/BpenZ9yntKIH9wxOKmdFfD4UfoyBrx8/ZE09NkO > ir23M8jOqteTxqtprnuNKBjjOZxUXbErYgvnaOFCdFYkkJZQtsk0dypGWYXI6QRh > UYwxEvvWCXaFfBbOFoMXWUrkqqVEO+l6wWmXkW57HGpFMbsgiOddDzflUKMdif3+ > qA0ObL72ndekshPdZcaaD12OBNVYkgffgsHcd6VDA9h815iKS720X/uKRt5eBP9n > 7XyJtOV/JSMwvh+CVnDqY+oqKW+FbCV8l1VeE7E2nSTHwSG8z5IG6cIrjfdYtaAK > OvTuRC0vimeDS7c9fpp2TFEmZ63pN4Tsfq+hF1Ch0gR5etJZQuA= > =1M6s > -END PGP SIGNATURE- > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging
On Tue, Jan 23, 2018 at 9:00 AM, wrote: > > > - Mail original - > De: "Neal Gompa" > >> As long as I can do Obsoletes/Provides for the old name for the devel, >> unit-test, > > BTW is anyone using the unit-test packages? Right now I do not generate them, > I don't need them, and making them work with autodeps would be hairy > (deploying without autodeps should be trivial however) > > To be honest, given all the parts current packages fail to install, I'd > expect many of the current unit test packages to fail in mysterious ways, so > I'm curious: what use has been found for them? > No idea, but I just checked, and I don't even have the unit-test subpackage enabled on snapd, so I don't particularly care too much there... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging
- Mail original - De: "Neal Gompa" > As long as I can do Obsoletes/Provides for the old name for the devel, > unit-test, BTW is anyone using the unit-test packages? Right now I do not generate them, I don't need them, and making them work with autodeps would be hairy (deploying without autodeps should be trivial however) To be honest, given all the parts current packages fail to install, I'd expect many of the current unit test packages to fail in mysterious ways, so I'm curious: what use has been found for them? Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Fedora-packaging] Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging
On Tue, Jan 23, 2018 at 8:54 AM, wrote:
>
>
> - Mail original -
> De: "Neal Gompa"
>
>>> 2. if your concern is that the *forge* macros are defective somewhere I'd
>>> be curious where as you'd be the
>>> first to report an actual technical problem. I've used them intensively in
>>> rawhide and el7 with many different
>>>rpm tools and they are rock solid for me
>>
>
>> I don't consider them defective. They make me a bit squeamish because
>> I don't see the spec preamble and such because they're autogenerated,
>> but you've mentioned that it's possible to selectively use these
>> things with Go and forge macros.
>
> I'm curious, what are you missing in the preamble ? As far as I can see it's
> all there (even though some values set to variables %gometa precomputes). I
> had it's right autogenerated some parts of it in the past but it's all
> converted to variable use now to avoid packager surprise and permit
> customization.
>
> For example, what are you missing there?
>
> %<---
> %global goipathgithub.com/hashicorp/consul
> Version: 1.0.2
>
> %gometa
>
> %global common_description %{expand:
> Consul is a tool for service discovery […]}
>
> Name:consul
> Release: 5%{?dist}
> Summary: A tool for easy service discovery, monitoring and configuration
> License: MPLv2.0
> URL: https://www.consul.io/
> Source: %{gosource}
> %<---
>
> Or here ?
>
> %<---
> %global goipathgithub.com/hashicorp/go-sockaddr
> %global commit 9b4c5fa5b10a683339a270d664474b9f4aee62fc
>
> %gometa
>
> %global common_description %{expand:
> Socket address convenience functions for Go. go-sockaddr is a convenience
> library…}
>
> Name:%{goname}
> Version: 0
> Release: 0.14%{?dist}
> Summary: A Go convenience library to manipulate IP Addresses and UNIX sockets
> License: MPLv2.0
> URL: %{gourl}
> Source: %{gosource}
> %<---
>
Actually, this is fine with me. This is what disturbed me a bit:
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_examples
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging
- Mail original -
De: "Neal Gompa"
>> 2. if your concern is that the *forge* macros are defective somewhere I'd
>> be curious where as you'd be the
>> first to report an actual technical problem. I've used them intensively in
>> rawhide and el7 with many different
>>rpm tools and they are rock solid for me
>
> I don't consider them defective. They make me a bit squeamish because
> I don't see the spec preamble and such because they're autogenerated,
> but you've mentioned that it's possible to selectively use these
> things with Go and forge macros.
I'm curious, what are you missing in the preamble ? As far as I can see it's
all there (even though some values set to variables %gometa precomputes). I had
it's right autogenerated some parts of it in the past but it's all converted to
variable use now to avoid packager surprise and permit customization.
For example, what are you missing there?
%<---
%global goipathgithub.com/hashicorp/consul
Version: 1.0.2
%gometa
%global common_description %{expand:
Consul is a tool for service discovery […]}
Name:consul
Release: 5%{?dist}
Summary: A tool for easy service discovery, monitoring and configuration
License: MPLv2.0
URL: https://www.consul.io/
Source: %{gosource}
%<---
Or here ?
%<---
%global goipathgithub.com/hashicorp/go-sockaddr
%global commit 9b4c5fa5b10a683339a270d664474b9f4aee62fc
%gometa
%global common_description %{expand:
Socket address convenience functions for Go. go-sockaddr is a convenience
library…}
Name:%{goname}
Version: 0
Release: 0.14%{?dist}
Summary: A Go convenience library to manipulate IP Addresses and UNIX sockets
License: MPLv2.0
URL: %{gourl}
Source: %{gosource}
%<---
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Unannounced SONAME bump in tinyxml2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 https://src.fedoraproject.org/rpms/tinyxml2/c/3600750a8f1b0eaa6cab346496fd75a07 ea749cb - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpnPSEACgkQaVcUvRu8 X0zgYBAAqfV6lP/OHdB/tsCsojIw/xjjSt+1jhQzuBO6Hlk22vUDkXeeueJG2IQF ej/eXR8/+GYOrV73vfH4z8XTWzbQuPWhnXak8qnJ052riwkr1lI1kLsD+IKi82kt cQDNGJ6BwMydIzUVYpF9XzCVMh8NdKtrS2VIBz4NjJk9jLhqVPY1kfm0qakTdpSI YajRfp4dlSwMC/LvUriY5I3aOIpogKKBog+VDxEUBhE9MI31af5ZX81RYJRA+lrT RXYxZHUc5b4xJ1vaUAziOYOZVfq2pE/rr+8aKtL4m+StKc09aHyYdF8p1zZAycpK mKdKs9mkR16E+Kjn3JriMtMH/BpenZ9yntKIH9wxOKmdFfD4UfoyBrx8/ZE09NkO ir23M8jOqteTxqtprnuNKBjjOZxUXbErYgvnaOFCdFYkkJZQtsk0dypGWYXI6QRh UYwxEvvWCXaFfBbOFoMXWUrkqqVEO+l6wWmXkW57HGpFMbsgiOddDzflUKMdif3+ qA0ObL72ndekshPdZcaaD12OBNVYkgffgsHcd6VDA9h815iKS720X/uKRt5eBP9n 7XyJtOV/JSMwvh+CVnDqY+oqKW+FbCV8l1VeE7E2nSTHwSG8z5IG6cIrjfdYtaAK OvTuRC0vimeDS7c9fpp2TFEmZ63pN4Tsfq+hF1Ch0gR5etJZQuA= =1M6s -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EPEL support in "master" branch (aka speeding up Fedora development)
On Tue, 2018-01-23 at 07:36 +0100, Igor Gnatenko wrote:
> On Mon, 2018-01-22 at 14:33 -0500, Matthew Miller wrote:
> > On Sat, Jan 20, 2018 at 02:23:16PM +0100, Igor Gnatenko wrote:
> > > What I'm trying to say here is that each time we want to
> > > implement
> > > some feature in Fedora, we either need to have some replacement
> > > in
> > > EPEL or diverge Fedora branches from EPEL branches. Having
> > > replacement is not always possible, especially if we start
> > > utilizing
> > > new (actually 8 years old) features of RPM.
> >
> > I'd really like to see us tend towards coming up with macros that
> > provide elegant fallbacks on EPEL. (The %license macro is a good
> > example.)
>
> There is no fallback for rich dependencies. There is no fallback for
> filetriggers.
>
> > I get the frustration with older stuff holding us back, but we
> > really
> > have a _lot_ of users who get value from doing so.
> > https://twitter.com/mattdm/status/936243506355621888
>
> I'm definitely not against supporting EPEL, but right now it is
> hurting me that
> much that I don't do that.
AWS (Amazon web services) technologies are based on Centos 6 and 7 ,
the recente announced "AWS Cloud9 a cloud IDE for writing, running, and
debugging code" is running in a Centos 6 ! and use epel repos ! maybe
that is why I more motivate to packaging for EPEL 6 .
TL;DR;
Can't we fix things on EPEL, to speed up Fedora devel ?
another story that is bugging me is python2 packages for example [1]
if we want call it python2-foo , so we have to guarantee that rule also
applies on RHEL(s) / Centos .
[1]
%if 0%{?fedora}
BuildRequires: python2-six
%else
BuildRequires: python-six
%endif
https://src.fedoraproject.org/rpms/wammu/blob/master/f/wammu.spec#_18
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unresponsive maintainer
2018-01-22 20:21 GMT+01:00 Matthew Miller : > > I saw him mention that he'll be at DevConf.cz, so maybe someone can > catch him there. That must have been last year. :-) Unfortunately I can't make it this time and only came last year to find new maintainers for my packages and meet with old friends. This being said I am still looking for maintainers for *all* of my packages and still look forward to meet all of you again. For personal reasons however, I will be busy in the coming months, so don't expect to meet me at FOSDEM, CevConf or other events. Best regards, Christoph ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EPEL support in "master" branch (aka speeding up Fedora development)
On Tue, Jan 23, 2018 at 07:36:08AM +0100, Igor Gnatenko wrote: > > I'd really like to see us tend towards coming up with macros that > > provide elegant fallbacks on EPEL. (The %license macro is a good > > example.) > There is no fallback for rich dependencies. There is no fallback for > filetriggers. I'd rather make big things like this be "break points" rather than have a preemptive global policy. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unresponsive maintainer
2018-01-22 1:23 GMT+01:00 Greg Evenden : > you might even be better to catch him over on the SUSE IRC channels, it might > be worth a shot to see if anyone in SUSE Packages those packages an are up to > date an Grab the Source RPM's from there Good idea, but this shouldn't be necessary. I'm working at SUSE now, but I'm not really active in openSUSE and not maintaining any packages there. I plan to do so – e.g. Xfce is better maintained in Fedora than in openSUSE – but I just don't find the time as lots of things have changed for me in real-life recently. Best regards, Christoph ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unresponsive maintainer
2018-01-22 0:38 GMT+01:00 Tao Zhao : > Hi Mamoru, > > Thanks for the information! I've pinged his gmail. Let's see how it goes. Hi Alick, sorry, I missed that mail. I have given up looking after individual packages, so make sure to use a meaningful subject if you want to catch my attention. ;-) But you are right, I am pretty much unresponsive. I am no longer using Fedora – just yesterday I replaced F22 on my old laptop with openSUSE leap 42.3 – and thus shouldn't maintain any packages. I have already given up many of them, but others are still looking for new maintainers. I wonder what the best way forward is. While I don't want to be responsible for them (in terms of bug reports, broken deps etc.), I still would like to have commit access in case I one day return to Fedora. Any suggestions what I should do? Mass-orphaning everything? And how would I actually do that? I'm not really familiar with how package ownership is handled in Fedora these days. Best regards, Christoph ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, 2018-01-23 at 10:32 +0100, Pierre-Yves Chibon wrote: > > We just sent an announcement about this, sorry for being late on this. > > Basically, you can "waive" test results using waiverdb-cli (dnf install > waiverdb-cli) which will allow the update to go through despite of the failing > test. > We're working on putting this into bodhi itself for easier use. Note, just waiving this kind of failure one-by-one doesn't seem like the proper fix for this to me. Patrick told me yesterday that he'd seen or been told about a different (I think) but similar case; I think there may be kind of a generic issue with the ABI diff test checking the ABI of shared objects that aren't actually 'public' in any meaningful way. We should look at that as a generic issue. I'm sending a mail to qa-devel@ to flag this up to the Taskotron devs. We could consider dropping this test from the gating list again until this is looked into... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: -z defs linker flag activated in Fedora rawhide
On Tue, Jan 23, 2018 at 02:04:26PM +0100, Florian Weimer wrote: > On 01/23/2018 01:49 PM, Daniel P. Berrange wrote: > > On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote: > > > I updated redhat-rpm-config to instruct ld to reject linking shared > > > objects > > > with undefined symbols. Such undefined symbols break symbol versioning > > > because the are not necessarily bound to the correct symbol version at run > > > time. (rhbz#1535422) > > > > > > ### Disable strict symbol checks in the link editor (ld) > > > > > > By default, the link editor will refuse to link shared objects which > > > contain undefined symbols. In some cases (such as when a DSO is > > > loaded as a plugin and is expected to bind to symbols in the main > > > executable), undefined symbols are expected. In this case, you can > > > add > > > > > > %undefine _strict_symbol_defs_build > > > > > > to the RPM spec file to disable these strict checks. Alternatively, > > > you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc > > > command line). The latter needs binutils 2.29.1-12.fc28 or later. > > > > This affects libvirt, because we have a tonne of dlopen()able modules > > which have undefined symbols that get resolved against the binary > > that's loading them: > > > >https://kojipkgs.fedoraproject.org//work/tasks/4413/24394413/build.log > > > > I'll add the "%undefine _strict_symbol_defs_build" stanza to the RPM > > spec for now. > > Some of these symbols are also defined in libvirt.so.0. In fact, in the > link failure above, I don't see a *single* symbol which isn't defined in > libvirt.so.0. And /usr/sbin/libvirtd has a DT_NEEDED entry for libvirt.so.0 > anyway, so it's not actually about loading libvirt.so.0. > > This looks more like the new style of doing plug-ins, where the shared code > is in a separate DSO which is linked from both the main application and the > plug-ins. In this case, maybe you can complete the transition and avoid > quite a bit of duplicate by removing the definitions from the main program? The stuff the modules depend on is probably all in libvirt.so, but I'm not 100% that's the case for all our modules - the build failure above stopped the build before getting onto many of our other modules. I'll have a go at explicitly linking the plugins with libvirt.so upstream though, to see if that's sufficient to kee the linker happy, and if so add '-z defs' by default to upstream's build. > If there is deliberate symbol interposition going on to alter the > functionality of libvirt.so.0, then this will continue to work even if the > plug-ins are linked explicitly against libvirt.so.0. I don't think we do symbol interposition > > I wonder if you can elaborate on what we should look out for wrt the > > glibc vs tirpc symbol resolution problem mentioned. libvirt uses > > XDR APIs, so is potentially affected by this. In rawhide, we are > > linking with an explicit "-ltirpc" line already though. Is that > > enough to avoid the problems you describe wrt xdr_* symbols getting > > incorrectly resolved ? > > The xdr_* symbols should have TIRPC_* symbol version. Then you are good. Ok, thanks. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, Jan 23, 2018 at 10:32:49AM +0100, Pierre-Yves Chibon wrote: > We just sent an announcement about this, sorry for being late on this. > > Basically, you can "waive" test results using waiverdb-cli (dnf install > waiverdb-cli) which will allow the update to go through despite of the failing > test. > We're working on putting this into bodhi itself for easier use. Can someone who knows what they're talking about put this into https://fedoraproject.org/wiki/Package_update_HOWTO?rd=PackageMaintainers/UpdatingPackageHowTo#Handling_feedback_from_automated_tests (Also, that document is a great candidate for conversion to the new docs system. Just sayin'.) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: -z defs linker flag activated in Fedora rawhide
On 01/23/2018 01:49 PM, Daniel P. Berrange wrote: On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote: I updated redhat-rpm-config to instruct ld to reject linking shared objects with undefined symbols. Such undefined symbols break symbol versioning because the are not necessarily bound to the correct symbol version at run time. (rhbz#1535422) ### Disable strict symbol checks in the link editor (ld) By default, the link editor will refuse to link shared objects which contain undefined symbols. In some cases (such as when a DSO is loaded as a plugin and is expected to bind to symbols in the main executable), undefined symbols are expected. In this case, you can add %undefine _strict_symbol_defs_build to the RPM spec file to disable these strict checks. Alternatively, you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc command line). The latter needs binutils 2.29.1-12.fc28 or later. This affects libvirt, because we have a tonne of dlopen()able modules which have undefined symbols that get resolved against the binary that's loading them: https://kojipkgs.fedoraproject.org//work/tasks/4413/24394413/build.log I'll add the "%undefine _strict_symbol_defs_build" stanza to the RPM spec for now. Some of these symbols are also defined in libvirt.so.0. In fact, in the link failure above, I don't see a *single* symbol which isn't defined in libvirt.so.0. And /usr/sbin/libvirtd has a DT_NEEDED entry for libvirt.so.0 anyway, so it's not actually about loading libvirt.so.0. This looks more like the new style of doing plug-ins, where the shared code is in a separate DSO which is linked from both the main application and the plug-ins. In this case, maybe you can complete the transition and avoid quite a bit of duplicate by removing the definitions from the main program? If there is deliberate symbol interposition going on to alter the functionality of libvirt.so.0, then this will continue to work even if the plug-ins are linked explicitly against libvirt.so.0. I wonder if you can elaborate on what we should look out for wrt the glibc vs tirpc symbol resolution problem mentioned. libvirt uses XDR APIs, so is potentially affected by this. In rawhide, we are linking with an explicit "-ltirpc" line already though. Is that enough to avoid the problems you describe wrt xdr_* symbols getting incorrectly resolved ? The xdr_* symbols should have TIRPC_* symbol version. Then you are good. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
