Re: KDE print dialog does not see CUPS settings
Marcel Oliver wrote: > Since I upgraded to F27, the KDE print dialog (for me the most > relevant application is okular) fails to see the available printer > options, nor does it see the printer defaults. It also does not save > changed settings from one print job to the next. Other applications > (firefox, libreoffice, evince, ...) see the CUPS settings just fine. > > This happens on the cinnamon desktop (Fedora cinnamon spin). > > I do not know if this is a KDE problem, a problem with KDE integration > in Fedora in general, or with the cinnamon spin in particular, or > possibly related to CUPS, but would be willing to help debug the > issue. This is actually a limitation (you can call it feature regression if you want) in Qt 5 that has been there since Qt 5.0.0. The reason you have not seen it before Fedora 27 is because Okular was still using Qt 4 until Fedora 25 (included). (I guess you skipped Fedora 26, because that already had a Qt 5 version of Okular.) Thankfully, as Rex Dieter points out, this is finally being addressed in Qt 5.11 (see https://wiki.qt.io/New_Features_in_Qt_5.11 and https://bugreports.qt.io/browse/QTBUG-54464). Unfortunately, that release is still a few months away from now. (Qt upstream currently expects to release Qt 5.11.0 on May 31.) I would actually argue that we should backport this to our packages sooner, backports from OpenSUSE are linked in QTBUG-54464. But I am not a maintainer of qt5-qtbase, so it is not my decision to make. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pull requests for compat-gcc-34
7.02.2018 14:58 Jonathan Wakely wrote: > > On 07/02/18 02:09 +0100, Rafal Luzynski wrote: > >[...] > >Also, just to clarify: I still don't know whether it is correct to just > >bump the required version of libstdc++, I just bump it because it has been > >done so many times in the past. > > "libstdc++ < 7.0.0" seems to be an attempt to ensure that an > ABI-compatible version of libstdc++ is used, and conservatively names > a version that is known to be compatible (rather than assuming that > all future versions will be compatible). > > The libstdc++ from GCC 8.x is ABI compatible with 3.4.x, so bumping > the Requires: to 9.0.0 (allowing any GCC 8.x release) is fine. Thank you for your review and the explanation, Jonathan. Of course, the reason why I bumped to "libstdc++ < 8.0.0" is that the version 8.0.0 has been pushed to Fedora only recently, after I had written the patches. > I'd be tempted to simply remove the version, so just have > Requires: libstdc++, or maybe Requires: libstdc++ >= 3.4.0 because > it's unlikely that libstdc++ will introduce an ABI break before that > spec file becomes obsolete. But maybe I'm not conservative enough :-) What about the things like: Requires: libstdc++.so.6 or Requires: libstdc++.so.6(GLIBCXX_3.4) ? Regards, Rafal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Attempting to contact unresponsive maintainers - xing, noriko, aortega, jcholast, mzatko
Greetings, we've been told that the email addresses for these package maintainers are no longer valid. I'm starting the unresponsive maintainer policy to find out if they are still interested in maintaining their packages (and if so, have them update their email addresses in FAS). If they're not interested in maintaining or we can't locate them in 1 week, I'll have FESCo orphan the packages so that others can take them over. If you have a way to contact these maintainers, please let them know that we'd appreciate knowing what to do with their packages. Thanks! xing: https://src.fedoraproject.org/user/xning Projects: https://src.fedoraproject.org/rpms/perl-Pod-Plainer [product: Fedora] noriko: Projects: translation-quick-start-guide [product: Fedora Documentation] Japanese [ja] [product: Fedora Localization] aortega: Projects: qpidpy [product: Fedora] qpidrb [product: Fedora] jcholast: https://src.fedoraproject.org/user/jcholast Projects: peervpn [product: Fedora] mzatko: https://src.fedoraproject.org/user/mzatko Projects: arandr [product: Fedora] rubygem-slim [product: Fedora] rubygem-awesome_print [product: Fedora] rubygem-colored [product: Fedora] arm-none-eabi-gdb [product: Fedora] kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Expenses and Reimbursements through the end of the year
Hi All, I am sending this out to multiple lists to get it wide exposure. Red Hat let me know about the year end closing dates in an email yesterday. In order for me to be able to get our items resolved on time, I need to request the following: 1) All reimbursements must be filed and paid by 15 February. This means you have to get your trip reports done and the receipts uploaded in time for the regional card holders (or me) to get you reimbursed by that date. The money can be in flight to you, but must have been sent from the CC. 2) Card Holders, please stop using your cards on the 15th of February at the close of your day local time. 3) Community members who happen to be Red Hat employees should also have everything processed and communicated to me so that we can ensure that your paperwork is submitted by 15 February as well. This is because of the extra processing load in many regions for cost transfers. These two actions are the best things we can do to ensure that our expenses land in this fiscal year and are not subtracted from our next fiscal year. If you have events which are going to happen after 15 February or a reason why you cannot get reimbursements submitted until after that please contact me. I have more direct access to systems than the card holders do and may be able to help. However, in general, you should expect to see these late charges removed from any budget that is allocated next year. As always, I am happy to help so don't hesitate to contact me. regards, bex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1542721] Please provide a package for EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1542721 --- Comment #4 from Robert-André Mauchin --- Yes only for EPEL of course. I need you to give me the permissions if you accept. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
[Bug 1542721] Please provide a package for EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1542721 --- Comment #3 from Ralf Corsepius --- (In reply to Robert-André Mauchin from comment #2) > Would you consider adding me as a co-maintainer so I can mairtain EPEL7 > version for perl(Text::Haml) and perl-Locale-Maketext-Lexicon? My FAS is > eclipseo. I don't know you and have never heard about you before. That said, feel free to take the EPEL branch, but I am not interested in having you as co-maintainer for Fedora. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
[rpms/bugzilla] PR #1: Update Python 2 dependency declarations to new packaging standards
ishcherb opened a new pull-request against the project: `bugzilla` that you are following: `` Update Python 2 dependency declarations to new packaging standards `` To reply, visit the link below https://src.fedoraproject.org/rpms/bugzilla/pull-request/1 ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
[rpms/perl-Inline-Python] PR #1: Update Python 2 dependency declarations to new packaging standards
ishcherb opened a new pull-request against the project: `perl-Inline-Python` that you are following: `` Update Python 2 dependency declarations to new packaging standards `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Inline-Python/pull-request/1 ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
[Bug 1542727] Please provide a package for EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1542727 Petr Pisar changed: What|Removed |Added Fixed In Version||perl-experimental-0.019-2.e ||l7 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
[Bug 1542727] Please provide a package for EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1542727 --- Comment #2 from Fedora Update System --- perl-experimental-0.019-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0a36dcf92a -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
[Bug 1542771] perl-Sub-Quote-2.005000 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1542771 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- perl-Sub-Quote-2.005000-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b51a128c50 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Re: Pull requests for compat-gcc-34
On 07/02/18 02:09 +0100, Rafal Luzynski wrote: Hello, I have opened 3 pull requests for compat-gcc-34: https://src.fedoraproject.org/rpms/compat-gcc-34/pull-requests fixing FTBFS errors in 3 currently existing Fedora releases. Thank you all who helped me with this task. What is the next step to make them actually merged? I have not received any feedback from the maintainer, I believe he's just very busy. Also, just to clarify: I still don't know whether it is correct to just bump the required version of libstdc++, I just bump it because it has been done so many times in the past. "libstdc++ < 7.0.0" seems to be an attempt to ensure that an ABI-compatible version of libstdc++ is used, and conservatively names a version that is known to be compatible (rather than assuming that all future versions will be compatible). The libstdc++ from GCC 8.x is ABI compatible with 3.4.x, so bumping the Requires: to 9.0.0 (allowing any GCC 8.x release) is fine. I'd be tempted to simply remove the version, so just have Requires: libstdc++, or maybe Requires: libstdc++ >= 3.4.0 because it's unlikely that libstdc++ will introduce an ABI break before that spec file becomes obsolete. But maybe I'm not conservative enough :-) I'll add comments to bugzilla. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 1066 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 dokuwiki-0-0.24.20140929c.el7 828 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f mcollective-2.8.4-1.el7 411 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d libbsd-0.8.3-1.el7 308 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe mod_cluster-1.3.3-10.el7 140 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23 libmspack-0.6-0.1.alpha.el7 77 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece nagios-4.3.4-5.el7 41 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b monit-5.25.1-1.el7 26 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65 rootsh-1.5.3-17.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-24ac4ff7df knot-resolver-1.5.3-1.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dd0bc449d7 konversation-1.5.1-4.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fb68becde7 w3m-0.5.3-36.git20180125.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-18ea640f19 tomcat-native-1.2.16-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f09712d924 pdns-3.4.11-4.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1 jhead-3.00-7.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing cacti-1.1.34-1.el7 gen-oath-safe-0.10.1-3.el7 mbedtls-2.7.0-1.el7 mozilla-https-everywhere-2018.1.29-1.el7 odcs-0.1.7-2.el7 p7zip-16.02-10.el7 petsc-3.8.3-4.el7 petsc4py-3.8.1-5.el7 php-cs-fixer-2.2.16-1.el7 wordpress-4.9.4-1.el7 Details about builds: cacti-1.1.34-1.el7 (FEDORA-EPEL-2018-ce2a9f86b7) An rrd based graphing tool Update Information: - Update to 1.1.34 Release notes: https://www.cacti.net/release_notes.php?version=1.1.34 gen-oath-safe-0.10.1-3.el7 (FEDORA-EPEL-2018-dd0ca17daf) Script for generating HOTP/TOTP keys (and QR code) Update Information: Update Python dependencies to ``python2-`` names. mbedtls-2.7.0-1.el7 (FEDORA-EPEL-2018-525417d3d4) Light-weight cryptographic and SSL/TLS library Update Information: - Update to 2.7.0 Release notes: https://tls.mbed.org/tech- updates/releases/mbedtls-2.7.0-2.1.10-and-1.3.22-released Security Advisory: https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security- advisory-2018-01 mozilla-https-everywhere-2018.1.29-1.el7 (FEDORA-EPEL-2018-9037430137) HTTPS enforcement extension for Mozilla Firefox Update Information: - More unspecified ruleset updates odcs-0.1.7-2.el7 (FEDORA-EPEL-2018-8e4530ce63) The On Demand Compose Service Update Information: Update to new version 0.1.7-2. p7zip-16.02-10.el7 (FEDORA-EPEL-2018-069884a87f) Very high compression ratio file archiver Update Information: Improved security patch Security fix for CVE-2017-17969 (from Debian) References: [ 1 ] Bug #1538457 - CVE-2017-17969 p7zip: heap-based buffer overflow in 7zip/Compress/ShrinkDecoder.cpp can allow an attacker to write arbitrary data and cause a crash https://bugzilla.redhat.com/show_bug.cgi?id=1538457 petsc-3.8.3-4.el7 (FEDORA-EPEL-2018-fc36db3960) Portable Extensib
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 938 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168 rubygem-crack-0.3.2-2.el6 828 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb mcollective-2.8.4-1.el6 800 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9 thttpd-2.25b-24.el6 411 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac libbsd-0.8.3-2.el6 140 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92 libmspack-0.6-0.1.alpha.el6 59 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e optipng-0.7.6-6.el6 41 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598 monit-5.25.1-1.el6 31 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462 heimdal-7.5.0-1.el6 26 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4 rootsh-1.5.3-17.el6 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-369a48191f clamav-0.99.3-1.el6 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fc6e2820ab tomcat-7.0.84-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing jhead-3.00-7.el6 mbedtls-2.7.0-1.el6 mozilla-https-everywhere-2018.1.29-1.el6 p7zip-16.02-10.el6 wordpress-4.9.4-1.el6 Details about builds: jhead-3.00-7.el6 (FEDORA-EPEL-2018-91712cdabe) Tool for displaying EXIF data embedded in JPEG images Update Information: Added Debian patch to fix CVE-2018-6612 (#1542049) References: [ 1 ] Bug #1542049 - CVE-2018-6612 jhead: Integer underflow in the process_EXIF function https://bugzilla.redhat.com/show_bug.cgi?id=1542049 mbedtls-2.7.0-1.el6 (FEDORA-EPEL-2018-3c8346d8e5) Light-weight cryptographic and SSL/TLS library Update Information: - Update to 2.7.0 Release notes: https://tls.mbed.org/tech- updates/releases/mbedtls-2.7.0-2.1.10-and-1.3.22-released Security Advisory: https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security- advisory-2018-01 mozilla-https-everywhere-2018.1.29-1.el6 (FEDORA-EPEL-2018-5a251eba13) HTTPS enforcement extension for Mozilla Firefox Update Information: - More unspecified ruleset updates p7zip-16.02-10.el6 (FEDORA-EPEL-2018-bc1949f307) Very high compression ratio file archiver Update Information: Improve security patch Security fix for CVE-2017-17969 (from Debian) References: [ 1 ] Bug #1538457 - CVE-2017-17969 p7zip: heap-based buffer overflow in 7zip/Compress/ShrinkDecoder.cpp can allow an attacker to write arbitrary data and cause a crash https://bugzilla.redhat.com/show_bug.cgi?id=1538457 wordpress-4.9.4-1.el6 (FEDORA-EPEL-2018-d2ebba1b36) Blog tool and publishing platform Update Information: Upstream announcements: * [WordPress 4.9.4 Maintenance Release](https://wordpress.org/news/2018/02/wordpress-4-9-4-maintenance- release/) * [WordPress 4.9.3 Maintenance Release](https://wordpress.org/news/2018/02/wordpress-4-9-3-maintenance- release/) ___ epel-devel mailing list -- epel-de...@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Re: COPR + pagure + rpkg HOWTO?
On Tue, Feb 6, 2018 at 1:54 AM, Miroslav Suchý wrote: > Dne 3.2.2018 v 15:45 Richard Shaw napsal(a): > > > > so I can stop uploading package to my fedorapeople public_html site and > build via URLs. > > Another option is to use > copr-cli build foo.src.rpm > which nowdays can submit src.rpm directly from your machine to Copr. This > feature is in Copr more than year. I may go that route but I was trying to find a workflow that's most similar to packaging for Fedora. Thanks, Richard ___ 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
Hi Nicolas, before I start arguing, I appreciate all your hard work on improving the Go guidelines, spending so much time explaining reasoning behind your decision. Also appreciating the effort on making the life easier for packagers, not just in the Go land, but throughout the distribution as well. There is a lot of great ideas in your Go proposal I would like to see implemented and widely used. The more transparent and easy-to-use spec files, the better for all maintainers. Let's keep moving forward, improving the infrastructure for other folks and pushing new ideas and improvements into practical solutions. On 12/17/2017 08: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 This proposal is integrated with and depends on thehttps://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft It builds on the hard work of the Go SIG and reuses the rpm automation ofhttps://fedoraproject.org/wiki/PackagingDrafts/Go when it exists, and produces compatible packages. Can you describe what you mean by "compatible packages"? I mentioned a list of things that you did not answer fully. Most important to me: - your macros do not generate build-time dependencies, which I see as one of the drawbacks. Do you plan to ignore them? - support for more subpackages. You describe how to specify which files go to which packages (https://fedoraproject.org/wiki/More_Go_packaging#Separate_code_packages) but you don't say how list of provided packages and a list of dependencies are generated for the subpackages. - reproducible evaluation of macros. Either for running automatic analysis over spec files or for debugging purposes. I would like the macros to be built in top of binaries I can run separately. With Jakub (jca...@redhat.com) we were discussing many times we could provide a minimal rpm built on top of gofedlib that would extract all the necessary pieces, including the naming convention so everyone can import provided library guided by the same rules as the guidelines enforce. I would like to see us synchronizing on this topic at some point. What it does: - drastically shorter spec files, up to 90% in some cases, often removing hundreds of lines per spec. +1 here, the shorter the spec file the better as long as it is still clear and transparent By better I mean: - easier to read, easier to understand, easier to adopt - less places to change and look if a spec file change is needed By clear I mean: - it is obvious what the spec file is actually declaring to do - it is easy to customize various parts (e.g. list of tests, list of dependencies) - simple, packager-friendly spec syntax +1 as long as each macro provides a single functionality. E.g. - generate a list of provided packages - generate a list of tests - generate a list of dependencies +1 to the %goname, %gourl, %gosource, %goinstall, %__goprovides, %_gorequires and other usefull macros as long as they are simple and transparent As long as the macros are optional and user can use any of them if it is suitable (suitable meant per a packager judgment). - automated package naming derived from the native identifier (import path). No more packages names without any relation with current upstream naming. Can you provide a list of package names that diverge from this convention? For historical reasons there are some packages that does not fall into the naming schema. Either because a go project got migrated to a different repo or because it make/made sense to combine some projects together and ship them in a single rpm. I don't mention Kubernetes, Docker and other popular projects as you already mention exception for them. - working Go autoprovides. No forgotten provides anymore. Sometimes it make sense to skip some provided package. E.g. some packages provide Windows specific code which has no use on Linux. So the claim is not completely valid. - working Go autorequires. No forgotten requires anymore. Depending on how you generate the list you can non-intentionally require more than is needed. Which causes installation of unneeded trees of rpms. E.g. for building purposes there is no need to install dependencies of tests So the claim is not completely valid. (Valid for both requires/provides): Sometimes you only need to install/provide a subset of a Go project. There are not many projects that imports every package another project provides. So to save time packaging dependencies of unimported packages (and their following maintenance), it is beneficial to generate only partial list of required/provided packages. Plus, in case CGO, there is no 1:1 ma
Re: Proposed Fedora packaging guideline: More Go packaging
- Original Message - > From: "nicolas mailhot" > To: gol...@lists.fedoraproject.org > Cc: "Development discussions related to Fedora" > , "Discussion of RPM packaging > standards and practices for Fedora" > Sent: Tuesday, February 6, 2018 7:34:03 PM > Subject: Re: Proposed Fedora packaging guideline: More Go packaging > > > > - Mail original - > De: "Jakub Cajka" > > Hi Jakub, > > >> And I'm sure any > >> attempt to strip the WIP bits from my side will be met with energetic > >> protests. > > > Have you tried that? What make you assume that? I'm sure that if you do it > > in constructive way, they will be accepted. > > My experience with humans is that they get attached to their bits of text > even when they have no time to finish them. But yes, I haven't tried, I > don't want to see a wiki page for a month after writing and formatting and > revising two separate packaging drafts. > > > I believe that technically exhausting document is needed as Go packaging is > > far from trivial. Sure it would be great to have > > (trivial) quick start guide. I think that your proposal fits that bill more > > than full documentation. > > IMHO that's exactly what FPC expects: a quick start document, not an in-depth > encyclopædia. In-depth is too hardcore to be validated by domain laymen, is > useless to onboard new packagers (which is the primary objective of Fedora > guidelines), is never finished because the state of the art changes, and > can't be applied to check whether a spec is good or not because in-depth > concerns *complex* cases where the "right" choice is not obvious, depends on > many factors that change over time, and usually requires asking the domain > experts directly. > > So you have the simple common cases, which are sufficient for most packagers, > and can be addressed by a formal document FPC can review and enforce, and > "other things" which are valuable but can not ever attain the formalness and > strictness level expected of Fedora guidelines, require continuous freedom > to edit, and are hosted in other Fedora wiki pages. At least that's how > real-life law is written (law text + expert commentaries) and how other > Fedora packaging SIGs function and got their guidelines approved. > > > They are used primarily to minimize build root size, by reducing the deps > > size and code size. > > Stripping example material from gopath installation filelists achieves the > same objective without all the complexity of managing packages that share > directories Go considers indivisible. ??, I have been talking about tests. From Go perspective source files and test source file, testdata are two distinctive sets. From my POV if your code depends for regular builds on tests code it means that there is something horribly wrong with your project(regardless of language used). Docs and examples would be great too, it should be in guidelines that packager must use reasonable effort to create subpackages with them. > > >> 7. even core Go people refuse to touch the subject with a 10 foot pole. > >> Sam > >> Boyer tried to demo a very small part of what would be necessary this week > >> end at FOSDEM and this part of his demo *failed*. I don't have the level > >> of > >> Go understanding Sam Boyer Has. > > > What has been demoed?? Unfortunately I could not make it there > > Sam Boyer presented the current state of his go dep prototype, and explained > his design choices (for example no nested projects which means the go import > path root becomes a core concept and it's useless to invest in splitting > projects as that usually requires nesting). He ended up stating go dep will > ignore tests by default, tried to demo optional test handling, and that > failed. He had another conference the next day I couldn't get to as I was > stuck in another part of the campus. Cool, there is recording for anyone interested https://fosdem.org/2018/schedule/event/dep/. > > > Have you met with Jan there? > > Unfortunately FOSDEM was its usual crazy stuff with multiple interesting > conferences at any given time and no hope of being admitted in a room if > you're late. So I've just been running from conf room to conf room without > any hope of meeting anyone :( > > > Your packaging proposal seems fairly monolithic and disregarding any prior > > art, so extensions will be very painful. > > Well, the creation of the proposal was a long suite of extending to cover > more cases (that's why some macros are rather long and convoluted), so I'm > quite sure extension is possible. Of course I may miss something, if you > identify a roadblock please point it out. > > >> You want to test one of my packages, fine, just rebuild it. That will run > >> unit tests *and* build the project binaries (which are also a form of code > >> testing, and a very thorough one at that). > > > I don't think that is great user experience nor packagers/maintainers > > experience. > > That's pretty much how rpm pre
Orphaning apigen, nette framework and some others
I just orphaned, because lack of time, lack of interest and lack of upstream collaboration : apigen php-apigen-theme-bootstrap php-apigen-theme-default php-kdyby-events php-kdyby-strict-objects php-latte php-nette php-nette-application php-nette-bootstrap php-nette-caching php-nette-component-model php-nette-database php-nette-deprecated php-nette-di php-nette-finder php-nette-forms php-nette-http php-nette-mail php-nette-neon php-nette-php-generator php-nette-reflection php-nette-robot-loader php-nette-safe-stream php-nette-security php-nette-tester php-nette-tokenizer php-nette-utils php-tracy Remi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: openclonk-0.8 linking fails
in the meantime, the issue is discussed here https://github.com/openclonk/openclonk/issues/64 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
