s390x chroots added to Copr
On Tue, 28 Jul 2020, Silvie Chlupova wrote: > Epel 7 isn't built for s390x architecture at all, so we don't have the > needed mirrors to build against. It will not be enabled. The ClefOS 7 binaries include all of EPEL 7 and more http://download.sinenomine.net/clefos/epel7/ -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Weekly: 2020-04-04
On Mon, 6 Apr 2020, Leigh Griffin wrote: > We cannot take the view of a singular person and make changes based on > that, we defer to them for prioritisation and their input. That's how the But, having reviewed the 'wishlist' of criteria quoted last week, [in the thread with Ben Cotton's message last Friday -- I believe the URL to the list directly was posted in the thread: CPE Git Forge Decision, but cannot lay my hands on it presently], it very obviously had not been winnowed down or curated down into any sort of rank order priority, or even something as simple as an Agile set of cards, sorted into stacks: - Must be present, showstopper if absent - Expected, but not critical if absent - Nice to have, but 'neh' ... so that task decomposition could proceed. If it had been openly done, with actual stakeholders at the table, the 'Must be free sources' criteria would have been in that top pile, and remained there. Without that 'polestar', other criteria were treated as critical As an outsider (from CentOS 1 era), who votes in each Fedora election, it looks as a non-transparent result is being 'justified' ex post If there are unacceptible non-Free parts at Gitlab to the Fedora vision of attainable via no non-freely licensed package, I'd be studying how to relieve the non-free constraints in Gitlab, rather than 'fighting City Hall' Just my thoughts, -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Embedded font support for PDFs is lacking; response to: Fonts packaging guidelines change status
Subject: Fonts packaging guidelines change status On Sat, 7 Mar 2020, Nicolas Mailhot wrote: > WHAT IS IT ALL ABOUT > > On 2020-02-13, FPC approved a rewrite of our fonts packaging > guidelines. and again that was published on the 14th removing some top matter through the Section mark: NEW PACKAGES STILL PENDING REVIEW, and advancing PR status on a couple of fonts But this question in the fonts-list was not addressed (see the bottom of this resend to include the devel list): Is a formal 'bug' needed to track this ? Background: That re-write draft as included does not address PDF portability The Fedora most recent prior approach on fonts neglected explicitly supporting the need of Latex chain created documents for type 1 fonts to be embedded in PDFs. From raising this issue previously, it is my understanding that Type 1 fonts are felt to not screen render as well as some later alternatives, but when it comes to generating a Portable Document to reliably render 'the same', one HAS to carry and prefer embedded fonts when present Detection of the issue, and Problem summarized: When one is missing fonts, and runs something like: dvips -t letter -Ppdf -G0 -j0 mypaper.dvi \ -o mypaper.ps one will get a 'missfont.log' as to an inability to embed a required font, 'required' for completeness for portability purposes See the discussion at: https://helpx.adobe.com/acrobat/using/pdf-fonts.html and its practical implication is discussed at: https://blogs.adobe.com/acrolaw/2007/11/pdf_creation_and_font_embedding/ The TL;DR takeaway is: The USPTO requires that PDF must be: Acrobat 4 (PDF 1.3) or higher (See note at end of article) No larger than 8.5? by 11? or A4 page size Have all fonts embedded and subset It is not JUST preparation of documents for filing there, but also for submitting 'camera ready PDF copy' to Lulu print on demand. Lulu is a child of Robert Young [a serial entrepreneur who is best known for founding Red Hat Inc] https://connect.lulu.com/en/discussion/33148 https://connect.lulu.com/en/discussion/33681/pdf-creation-settings-how-can-i-be-sure-my-pdf-will-print-correctly pull requirement: All fonts should be converted to outlines and embedded Way forward: There is a collection of 13 fonts provided under a freely reproducible license from Adobe, known as the Base 13 fonts - Courier, Courier-Bold, Courier-Oblique & Courier-BoldOblique - Times-Roman , Times-Bold , Times-Italic & Times-BoldItalic - Helvetica, Helvetica-Bold, Helvetica-Oblique & Helvetica-BoldOblique - Symbol [ but not: - ZapfDingbats ] I understand that they were removed from Fedora, as the Base 13 are Type 1 fonts but dang it, at least for purposes of completeness to be able to generate legal documents, and to permit me to continue to use FOSS tools to publish for fulfillment at Lulu, can we get these Type 1 fonts back, regardless of slight risk of aesthetic discontent ? Is a formal 'bug' needed to track this ? Thank you -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390x builder problem? disk full, or ?
On Wed, 19 Feb 2020, Kaleb Keithley wrote: long ago diskcheck was in Centos 2, and early Fedora /var/ftp/pub/nfs/mirror/redhat/fedora/1/SRPMS/diskcheck-1.4-5.src.rpm Why not build and install it so the admins would get warnings ? Also, when a build fails for: error: create archive failed on file cpio: write failed - No space left on device why not also emit a fedbus, or related message ? -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: More than 10% of all Fedora spec files are not POSIX sh compliant
On Mon, 25 Mar 2019, Kevin Fenzi wrote: > > explicit in this way instead of having the default be sh, but then tell > > people sh must be bash? > > Doesn't bash behave slightly differently when invoked as 'sh' ? bash behaviour has changed [1] over time --- /bin/sh is fixed in behaviour It is pretty clear that feaping creaturitis is in play with the bash developer -- an addition (recently) of an inbuilt 'seq' primitive was a surprise to me; lots of 'undocumented' behaviours discussed, and some 'promoted' to being documented. May one rely on undocumented behaviours? -- Russ herrold 1. https://tiswww.case.edu/php/chet/bash/CHANGES ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: missing -devel packages in 8 beta
On Tue, 11 Dec 2018, Dave Love wrote: > Obviously I can do that and set up a repo for use with mock, but you > surely don't expect all package maintainers to do that. when it is testing a Beta in a new Major, I do not feel that is an unreasonable expectation There is also a .repo file which you may find useful at the URL mentioned in a moment > > I see later in the thread the suggestion to file a boog > > > > done: > > https://bugzilla.redhat.com/show_bug.cgi?id=1657930 > What's that reporting, as it's not visible? That is an unexpected behaviour, new since the Bugzilla reqork in the last few days, and with no obvious way to 'unlock' it on my part as Reporter ;( Anyone wanting to view it send me, off list, their RH bugzilla account email address, and mention of this bug nuber, and I will add as a 'cc' --- there is nothing 'secret' there ;) I requested access to sources , and bug assignee Josh was kind enough to point to: ftp://ftp.redhat.com/redhat/rhel/rhel-8-beta/ which are populated down sub links: 49M add-ons/ha/source/Packages/ 49M add-ons/rs/source/Packages/ 192Madd-ons/rt/source/Packages/ 8.9Gappstream/source/Packages/ 1.4Gbaseos/source/Packages/ -- Russ herrold ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] missing -devel packages in 8 beta
On Mon, 10 Dec 2018, Dave Love wrote: > Does anyone know what the situation is with -devel packages in RHEL8 > beta? Many seem to be missing, so it's difficult to test EPEL builds > for 8, and you can't necessarily rebuild ones that are shipped in the > distribution; an example is openmpi, with most of the BRs missing. (I > can't even do useful chain builds because that's failing for chains of > three, which I should try to debug.) There are yum archves to enable per the release notice; also, DVD ISOs are available to retrieve and loop mount What particular -devel are you seeking? Is it non-versioned, such that you can work-around with an earlier one? Customarily I would just bootstrap forward to a needed leaf node package from the sources ... That said, I don't find a SRPMs' DVD. Sort of a strange omission in light of the making available of binary RPMs I see later in the thread the suggestion to file a boog done: https://bugzilla.redhat.com/show_bug.cgi?id=1657930 -- Russ herrold ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
On Fri, 19 Oct 2018, Chris Adams wrote: > Once upon a time, R P Herrold said: > > This seems very tone deaf and lacking in introspection, Matt > > > > perhaps by reading the subject line you chose to start this > > thread with > > Matt didn't choose that - that subject was set by Gerald B. Cox. If you say so (and I have no reason to doubt, but cannot confirm, so: sorry for the mis-attribution, Matt) ... at the URL in your email message headers is a link to: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KXPPKQNLJ6SZBUHKBMLB4OZY7WA77FGP/ Perma-link: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3MZCLLM47LIO6LFJC33RIFJHTIKQPFWP/#KXPPKQNLJ6SZBUHKBMLB4OZY7WA77FGP and at that page, the link titled ' Back to the thread ' points into a wholly different discussion https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3MZCLLM47LIO6LFJC33RIFJHTIKQPFWP/#KXPPKQNLJ6SZBUHKBMLB4OZY7WA77FGP One more reason to dislike KyperKitty hashes over pipermail -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
On Fri, 19 Oct 2018, Matthew Miller wrote: >> Neal Gompa: >> because you're dead set on this anyway. > Matt Miller: > I ... don't know how to engage constructively with this accusation, because > it it seems to come from absolutely nowhere. Yes, we're *definitely* trying This seems very tone deaf and lacking in introspection, Matt perhaps by reading the subject line you chose to start this thread with No mention of trying out, no mention of a trial. Just the usual 'this is a done deal' announcement on an extremely high volume mailing list I had trialled Discourse six months ago, leaving it on for days at a time. The web client had a leak down in it somewhere, My baseline load average went up and I ended up with a frozen web browser once all free ram and swap was exhausted. Migrate or not as you wish, it will simply be another place where Fedoraproject went off the tracks, chasing a mythical low involvement 'tire kicker' instead of supporting developers using mature tools and technologies (mailing lists, bugzilla, procmail sorting, mutt or alpine) The non-migratation capabilities of early MM3 efforts have been detailed earlier in this thread. Hyperkitty pretends a 33 character hash conveys more information than the MM2 model for pipermail, or say: MMDD-, but no-one was willing to critique a bad choice Pagure is great and all, but I recall filing a bug ... somewhere ... pagure, git, how knows ... about a cross-site inter-panel info leak, but there is no SPOT -- single point of truth -- in Fedora's hall of mirrors to find it later ad hoc. That does not happen with Bugzilla as I have a portfolio of several dozen custom searches that would reveal it to me with a couple clicks But charging off to a new shiny hill seems more important to Fedoraproject ** shrug ** -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Guideline change: glibc malloc as the C/C++/Rust allocator
On Mon, 30 Jul 2018, Jonathan Wakely wrote: > On 26/07/18 12:45 -0400, R P Herrold wrote: > > The use here of 'interpose' is unclear to me -- are you saying > > 'substitute a different' ? > > The usual way to replace 'malloc' is via ELF symbol interposition: > https://www.airs.com/blog/archives/307 noted -- thank you -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GIOFBZ6H233YYWKPK6HRBDB6EFYT3NSM/
Re: Guideline change: glibc malloc as the C/C++/Rust allocator
On Thu, 26 Jul 2018, Florian Weimer wrote: > > Could you please mention a couple of bugs where this is shown? > > https://bugzilla.redhat.com/show_bug.cgi?id=1237260 > https://bugzilla.redhat.com/show_bug.cgi?id=1303323 > http://www.erahm.org/2016/03/24/minimum-alignment-of-allocation-across-platforms/ thank you !! -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E55QFSM7IMU2SJF2NRXXH4XUF2DY2PEO/
Guideline change: glibc malloc as the C/C++/Rust allocator
On Thu, 26 Jul 2018, Florian Weimer wrote: > I would like to request a change of the Packaging Guidelines, advising > packagers not to interpose malloc. The use here of 'interpose' is unclear to me -- are you saying 'substitute a different' ? > The reasons are: > > * We have resources to support glibc malloc, but not for other mallocs. > * Other mallocs do not follow ABI and provide insufficient alignment. > * Choosing a malloc is workload-dependent and forcing a non-default > malloc takes options away from system administrators. Could you please mention a couple of bugs where this is shown? Thank you -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LGKMQWIVDFF3BP6PIITZZWLZG2BN4FSO/
Orphan packages will be retired if they remain orphaned for six weeks"
On Thu, 26 Jul 2018, Miro Hrončok wrote: > Is $subj [1] an automated or manual process? Shall I retire packages I've > orphaned before more weeks or just wait? > > [1] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers NONE of the outlinks to the actual packages at: Lists of Orphan and Retired Packages [ RH, EPEL 5, EPEL 6, or EPEL 7 ] actually work, of course (links as on that page, below) I think proceeding is premature, when a person cannot in good faith, review what is to be dropped -- Russ herrold https://admin.fedoraproject.org/pkgdb/orphaned/?status=Orphaned=master https://admin.fedoraproject.org/pkgdb/orphaned/?status=Orphaned=el5 https://admin.fedoraproject.org/pkgdb/orphaned/?status=Orphaned=el6 https://admin.fedoraproject.org/pkgdb/orphaned/?status=Orphaned=epel7 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PKSL2OQOXDDMEQ6OHLCOTNP3EKTNFJJE/
Re: [EPEL-devel] Re: python 2 retirement commo efforts
On Thu, 19 Jul 2018, Miro Hrončok wrote: > > The ** POINT ** of producing such a report is to 'put > > numbers' on the scope of the work rather than loose armwaving > > assertions such as: > > > > > Fedora still has more than 3000 packages depending on > > > python2 – many more than we can support without upstream > > > help. > > Those are real Fedora numbers [0]. No armwaving involved. > > 1311 python2 only packages > 1734 python2+python3 packages > + 88 with packaging problem where I'm not sure > > That is something between 3045 and 3133. That can be rounded to 3k. > > No idea why we moved the discussion to another list as well, but stop accusing > us from armwaving. We have data (for Fedora, because that where we started the > discussion). As for RHEL/EPEL: current ones can remain as they are. Future > ones see [1]. "accusing" ? I think it is pretty clear that more than a little projection is going on here. I offered a description of methodology, hard numbers on six archives, and the generation script to nail down numbers. Before your most recent email, nope The _reason_ that it was off an EPEL thread (EPEL of course being PART OF FEDORAPROJECT, last time I looked) is that is the harder one to solve, and also there was a thread going as to planning a meeting, of which that hard data was a part If I go to a car dealer and seek to buy a car and ask a price, and am told by the salesperson: "more than 3000" dollars they have not yet not told me a price they will sell the car at -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E4FYVZMRWLMIQ6L7PIJMBV6R2K4GMD7C/
Re: python 2 retirement commo efforts
On Tue, 17 Jul 2018, R P Herrold wrote: > I've poked at getting accurate counts and manifests of unique > python(2) package SRPMs off my mirror today -- I'll supplement > this email with the script and links to the mainfests > tomorrow. A 'sort | uniq' let me down as to getting an > accurate count released today tomorrow arrived on me, but here are the promised report and links to the results and the generator script [/share/MD0_DATA/Mirror/lftp] # time ./stats.sh # packages starting with target: python # but NOT python3 # collated from a mirror: 20180718 264 /tmp/redhat_rhel_SRPMSonly_6Server.txt 475 /tmp/redhat_rhel_SRPMSonly_7Server.txt 644 /tmp/redhat_epel_6.txt 825 /tmp/redhat_epel_7.txt 2776 /tmp/redhat_fedora_fedora-28.txt 2132 /tmp/redhat_rawhide2017.txt real64m28.714s user1m11.330s sys 3m6.450s The first column is the number of unique SRPMs for a given archive, seen. Inside the files (the link of which is my second column and the basename of which is accessible per the links below) are detail counts of the number for each distinct SRPMs within a given package name, as seen on a local private mirror I use and maintain Copies of the detail, and of the script producing the reports are at: http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_6Server.txt http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_7Server.txt http://gallery.herrold.com/stuff/redhat_epel_6.txt http://gallery.herrold.com/stuff/redhat_epel_7.txt http://gallery.herrold.com/stuff/redhat_fedora_fedora-28.txt http://gallery.herrold.com/stuff/redhat_rawhide2017.txt http://gallery.herrold.com/stuff/stats.sh The _purpose_ of getting the count of 'number of updated packages' for each given package is to permit seeing 'hot spots', and the 'no issues' 'build once and forget' packages particularly in RHEL and EPEL. Because of the way that current Fedora and RawHide are built, there is churn on rebuilds, even with non-material internal changes. THe The ** POINT ** of producing such a report is to 'put numbers' on the scope of the work rather than loose armwaving assertions such as: > Fedora still has more than 3000 packages depending on > python2 – many more than we can support without upstream > help. I did not try to structure and run a report to try to enumerate and count by dependencies. Looking at the problem with such a statistic, as to 'upstream' 'keystone' packages will, I suspect, show that many of the dependencies almost certainly 'cluster around a few 'branch' packages -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/W6XBLTIY5QLTSU4FBRDXHA3UCEH4PL43/
[EPEL-devel] Re: python 2 retirement commo efforts
On Tue, 17 Jul 2018, R P Herrold wrote: > I've poked at getting accurate counts and manifests of unique > python(2) package SRPMs off my mirror today -- I'll supplement > this email with the script and links to the mainfests > tomorrow. A 'sort | uniq' let me down as to getting an > accurate count released today tomorrow arrived on me, but here are the promised report and links to the results and the generator script [/share/MD0_DATA/Mirror/lftp] # time ./stats.sh # packages starting with target: python # but NOT python3 # collated from a mirror: 20180718 264 /tmp/redhat_rhel_SRPMSonly_6Server.txt 475 /tmp/redhat_rhel_SRPMSonly_7Server.txt 644 /tmp/redhat_epel_6.txt 825 /tmp/redhat_epel_7.txt 2776 /tmp/redhat_fedora_fedora-28.txt 2132 /tmp/redhat_rawhide2017.txt real64m28.714s user1m11.330s sys 3m6.450s The first column is the number of unique SRPMs for a given archive, seen. Inside the files (the link of which is my second column and the basename of which is accessible per the links below) are detail counts of the number for each distinct SRPMs within a given package name, as seen on a local private mirror I use and maintain Copies of the detail, and of the script producing the reports are at: http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_6Server.txt http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_7Server.txt http://gallery.herrold.com/stuff/redhat_epel_6.txt http://gallery.herrold.com/stuff/redhat_epel_7.txt http://gallery.herrold.com/stuff/redhat_fedora_fedora-28.txt http://gallery.herrold.com/stuff/redhat_rawhide2017.txt http://gallery.herrold.com/stuff/stats.sh The _purpose_ of getting the count of 'number of updated packages' for each given package is to permit seeing 'hot spots', and the 'no issues' 'build once and forget' packages particularly in RHEL and EPEL. Because of the way that current Fedora and RawHide are built, there is churn on rebuilds, even with non-material internal changes. THe The ** POINT ** of producing such a report is to 'put numbers' on the scope of the work rather than loose armwaving assertions such as: > Fedora still has more than 3000 packages depending on > python2 – many more than we can support without upstream > help. I did not try to structure and run a report to try to enumerate and count by dependencies. Looking at the problem with such a statistic, as to 'upstream' 'keystone' packages will, I suspect, show that many of the dependencies almost certainly 'cluster around a few 'branch' packages -- Russ herrold ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/W6XBLTIY5QLTSU4FBRDXHA3UCEH4PL43/
[EPEL-devel] Re: python 2 retirement commo efforts
On Tue, 17 Jul 2018, Kevin Fenzi wrote: > I'm confused here. I doubt very much RHEL is going to drop > python2 from rhel7. Thus epel7 packages should be able to go > on as they have... I've poked at getting accurate counts and manifests of unique python(2) package SRPMs off my mirror today -- I'll supplement this email with the script and lings to the mainfests tomorrow. A 'sort | uniq' let me down as to getting an accurate count released today Yes, for now there is not an issue, but I was just looking ahead to 2024 06 30 (the current published RHEL 7 initial EOL, pre Extended), and figuring out the enterprise user conversion loads, assuming RHEL 8 (tm) drops with a simple python(3), and no backward support python(2) -- Russ herrold ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/3PZMLIEJNDCNBB7H3HT3EUWTMWPOAEOJ/
[EPEL-devel] python 2 retirement commo efforts
notwithstanding my post on the f-devel ML, ... Probaby there should some work on communicating the need to turn down EPEL 6 at 2020 11 30, and with it those python 2 modules by that time Smooge, if from the logs you can comb mirroring apart from installlation pulls, having a ranked list of python(2) candidates, to point The python 2 in EPEL 7 (I see a mess of them), despite under 40 or so python 2's in base / update RHEL, it may make sense to see of one of the automated conversion rubric will work on say 80 pct of the packages there. Perhaps simply filing bugs asking the question for each, so we can garner some stats -- Russ herrold ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/FXUP362ZU4WCCWOXTJFS7C2Y7ZINGPA2/
Re: Intent to orphan Python 2
On Mon, 16 Jul 2018, Miro Hrončok wrote: > On 23.3.2018 12:23, Petr Viktorin wrote: > > tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need > > to start dropping python2 packages now. tl;dr: --- that statement by itself overlooks the obvious. Not ALL packages become unsupported that first day of that year > > Python 2.7 will reach end of upstream support on 1st of January, 2020, > > after almost 10 years (!) of volunteer maintenance. Not to be too direct about this, but isn't the RHEL 6 primary maintenance date (through 2020 11 30) a closer maintenance depot to look at and to compare against ? Packages NOT in RHEL have a closer date, perhaps, but RHEL (next, assumedly 8, but ...) has not dropped yet. A subscription customer _should_ be migrating toward 7 at this point, but as this is not a costless thing, such migrations tend to be ... with a deliberate pace -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V6TXSNJ7ER4SBK2D6L4BWU7YLLARJE7T/
Removal of GCC from the buildroot
On Fri, 13 Jul 2018, Miro Hrončok wrote: > I've clicked randomly trough failures during the mass rebuild at [1]. > > I see quite a lot of commands not founds for gcc, cc, c++... > > I think the maintainers should add them and that's fine, but it seemed that > during this change you said you will add those. Did it happen? > > [1] https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html This list seems to only cover packages starting with an uppercase letter, or a letter before lowercase 'i' also, it only lists one maintainer, and omits co-maintainers Would it be possible for a full list to be produced, and once done, mentioned here? thank you -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OOTIINKWTKOHFCPSEA67FC4BKD62EGSU/
Re: Packages which use the BuildRoot: directive
On Thu, 12 Jul 2018, Miro Hrončok wrote: > > > The guidelines currently say: Are these Holy Writ, or just process, subject to amendment? > > > I think this guideline is bad and counterproductive, since many > > > packages clearly ignore it. There is a principle: Seek first to understand before ** suggesting ** what one feels are helpful suggestions It applies here > > > So what do we do? Take the package away from > > > (most likely) upstream developers? oh -- So forking, or adding (probably) unwanted co-maintainers, or continuing to fight that entropy with what are functionally an unknown number of 'provenpackagers' co-maintainers, pushing unwanted 'fixes' in, is proposed? and a peeve: NOT updating the changelog when literally thousands of packages are re-factored? I know I always love getting to play detective, when an encountered version does not match a prior SRPM of the same NEVR > > > Tell them no no no very sternly so > > > they can ignore us? If being ignored bothers you, perhaps the problem is not them, but your reaction at being ignored Perhaps offer of the carrot rather than use of the stick is in order. Maybe, just asking questions, and coming up with a rubric to annotate within a non-parsed field in a .spec file where 'upstream' is (as was suggested -- as was done with the various side adjunct repos -- dag, RF, more, to accommodate their tooling) > > projects. So we do have leverage. great -- using force always makes new friends ... NOT What happened to the Four Fedora F's ? > always a Red Hat maintained software, where people were > basically telling us: "no, we won't accept your PR here, we > maintain the specfile somewhere else". 'Always'? A fork of 'Spacewalk' just left because of the non-public approach to road-map by Red Hat insiders, and simply ignoring or not taking non @redhat commits. I spoke with Don Vosburg of SUSE at a conference about his frustration with having to do so just a week or two ago. He _wished_ the fork was not required, but to maintain the their implementation, which is productized as 'SUSE Manager', he had to get that fixes in See again, seeking to understand first before suggesting prescriptions to the person ** volunteering ** to do work which happens also to benefit the Fedoraproject The project is a social voluntary organization -- driving volunteers AWAY is trivially easy. I took heat in the CentOS project for working to keep the Signal to Noise ratio high, at the expense of intentionally (and by a rubric documented in the CentOS wiki) removing people unwilling to play by that set of rules. I'd do it the same way again tomorrow. But I knew I was not being welcoming to all, as not all were welcome, frankly. Immediate kick-bans of people using profanity, racist content, etc, seem to be a win to me > It was very unpleasant experience and usually such maintainers expects us to: Again, the location of the hurt feelings is not with the remote maintainer. Examining ** why ** you feel that way is in order. Perhaps an out of band discussion with the recalcitrant offender is in order ;) Looking at my sent folder, I see that I send 20 to 30 'off list' emails a month, to get at the reasoning of another behind things I do not understand I find that it is very unpleasant to encounter a auto-closed bug, doing research as to an error, and knowing full well that this close is saying: This bug (and the current item I am researching) is known, but we did not fix it, so we swept it under the rug. Perhaps it will fix itself At that point, I can solve my unhappiness by: committing a local fix, and NOT upstreaming it - or - committing a local fix, and upstreaming it Obviously one path is better than the other for 'improving the breed' -- but if I have been filing ignored bugs, which simply get auto-closed, it is easier to do less work > Some maintainers were kinder than others, taking the changes and applying them > in their god-knows-where maintained spec files. Some where not. And, frankly, that is their choice to make, rather than yours, unless you are proposing to excommunicate people from Fedoraproject > We don't need to make the rule less strict, we need to find a way to enforce > it. The current state (people ignoring this rule) makes contributing to Fedora > even harder than it already is. "The beatings will continue until morale improves" kindly, -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QMHUKQNSCP65XNYWJOJREXQDDAQIKSEM/
Re: Removal of GCC from the buildroot
On Mon, 9 Jul 2018, Matt Milosevic wrote: > I tend to agree with Chris on this. Whether we like it or not, GCC is an > integral part of the Unix environment and most things we care about utilize > it in some aspect, even when it's not immediately obvious. Attempting to > forcefully bring in an alternate compiler would undoubtedly break a great > deal of things. Who said ** anything ** about more than a virtual provide, which will do ... nothing more than put in place a portable way to test for breakage ??? To the contrary, widely hard-coding BR: gcc locks OUT such efforts to track down 'gcc-isms' -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DVDAYZIM2L5MXEBVL7LLPCZPB3OYBQEN/
Re: Annobin: "causes a section type conflict with..."
On Mon, 9 Jul 2018, Florian Weimer wrote: > > Can the compiler team just merge the bloody plugin sources into the > > gcc source package so that it doesn't randomly break anymore? > > This change would add roughly 18 hours to the delivery of every annobin change > because that's the time required for building gcc. surely this can be conditionalized in the ./configure, and simply fire off a single local checking build instance daily on non-production builder, or if one ** 'needs' ** it every build [I sort of doubt it with the GCC build constellation], 'mock out' and only test the known pain points -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MQ6VPNXR5DQXLUAHJPBCPFFZKDWDKOXZ/
Removal of GCC from the buildroot
Removal GCC and friends from the buildroot is different than adding new conflicting BRs which impair Clang usability On Mon, 9 Jul 2018, Igor Gnatenko started: > > > I'm going to do this tomorrow. > > > > > > After which, I'm going to ask rel-eng to finally remove it from buildroot. > > > > > > This will happen before mass rebuild. Stay tuned. Tomasz Kłoczko wrote: > > After adding explicite gcc/g++ in BuildRequires it will be extreamly > > hard to switch use for example to use clang. > > > > Congratulation. and this snipeing came in from: Przemek Klosowski: > Come on now... You 'tutt tutt' this objection, but it seems that the secondary effects of the change are not well thought through. As an alternative, adding a 'virtual build requirement' such as for: BR: CCP-compiler and adding a manual: Provides: CCP-compiler to: gcc-c++ and so forth, would make this a non-invasive change. Why ** not ** choose such a route? Obviously, clang would also need a manual: Provides: CCP-compiler -- What is the need to force breakage, rather than doing it in 'friendly' way? -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2KHMIXPDF4YSKJ6CU3XBMFVPQRZMVA3M/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Mon, 18 Jun 2018, Lennart Poettering wrote: > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote: > > > The cited BLS spec is the original one, [1] ... later: L.P.: > [reduce] the size of the spec if possible, and drop as many > bits of it as we can, i.e. the stuff noone implements > anyway. > > > The cited BLS spec requires $BOOT be VFAT, are we doing that? Will cgroup and SElinux protections work in VFAT ? > Why would we? I mean the idea is that $BOOT can be shared among > multiple OSes installed. Which means one really should settle on a I see a lot of need in [1] for re-partitioning and optionally adding a /boot partition where none was specified, to make this work The move toward containers includes getting away from more than a single partition (and so, a separate /boot partition, as mostly irrelavant). Getting rid of a separate /boot partition is a win, as it removes the need for a separate mountpoint in /etc/fstab for a '/boot/'. partition, and all the gyrations as to partitioning in [1] N.B.: This is a 'Good Thing' as one does not get 'out of sync with each other between 'root of filesystem', and /boot/ when they are all in a single filesystem > So, in systemd we ship a generator that automatically establishes > automount points for the ESP. It will preferably use /efi as mount > point if it exists and is empty. If it doesn't exist or isn't > empty it will use /boot — if that exists or is empty. If neither exist > or are empty it won't do anything I think this last is a negative: > ... it won't do anything and I submit that the proper course, when no /boot partition is seen, is to properly mount the root of filesystem, and do a: mkdir /boot and then continue on To wrestle with all the failure modes, I see a lot of fall-through logic, and a lot more complexity, including re-partitioning by the boot loader on a device it may not have RW rights at the partition table level -- yikes, as to an added point of faiure -- outlined in the initial proposa [1]l, but not implied in Matthew Garrett's [2] But for the fact that that kernel updates do not 'just apply' with the current grubby / dracut regime, the approach of a /boot/ directory (but not separate partition) works in production just fine and has for over a decade [3] I suspect that moving to such as an option, and adding a systemd umount RW / remount RO of 'root of filesystem' on the way to a shutdown, would ameriorate if not totally remedy [4] and [5] as well. Just the remount RO by systemd will cause the needed 'sync' actions on the way down would solve: [6] and its Fedora twin: [7] If a '/boot/' partition is absent, simply creating a /boot/ directory at the root of the file system does away with the need for many of the gyrations of [1]. -- Russ herrold [1] https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ [2] https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=1498169 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1533620 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1569970 [6] https://bugzilla.redhat.com/show_bug.cgi?id=1464611 [7] https://bugzilla.redhat.com/show_bug.cgi?id=1466036 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QGECPUQBDZFIWDTYZRBJGIBHOVAIHALZ/
Re: F29 System Wide Change: Hide the grub menu
I think it was a fair question which was raised about the size of the audience being sought to be catered to, vs the mass of users of Fedoraproject code, and their 'least astonishment' and loss of acquired knowledge as to use If there are, oh, say, twelve people in the world that actually care about instantaneous GUI boots in Fedora, it is a waste of time to mess with this thread but to the most recent point raised about 'modifier keys'. I recall doing this back in DOS days with a third-party tool that permitted 'BAT files' to query for Shift, Alt, and Ctrl key states, and to build boolean decision trees: On Thu, 31 May 2018, Andrew Lutomirski wrote: > If the protocol were that the boot menu would be shown if > any key at all were held down, then we wouldn't need a 1 > second delay. or, perhaps, better still and less complex as in needing to suppress a boot menu, a message at the bottom of the GUI screen from its first appearance and for ten seconds or so: Hold either Shift key for more boot options so that a person could be habituated to holding a 'harmless' key. Harmless, in the sense that it does not fill and over-run a key-press buffer and start beeping at the holder I speak having personal setup options of: 15 sec timeout at the grub options menu with plymouth graphical stuff, rhgb, and quiet disabled always booting to a non-GUI console why: multi-user.target for something formerly though of as 'single user', although with multiple PTYs ?? with a 640x480 console which is NOT cleared away to support the fact that I am almost always remote and on KVM devices of varying resolutions, and so favoring a 'least common denominator' as to capabilities That last (preserving the TUI boot screen was tricky to find docoed Use: # systemctl edit getty@tty1 and add: # [Service] TTYVTDisallocate=no # as the description for the service -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BNQURFE2BWBLLII47V7DN7JTUNSTVCX3/
Re: /etc/profile.d/lang.sh -- still needed?
On Tue, 15 May 2018, David Kaspar [Dee'Kej] wrote: > It could at least tell us the current state of things, and maybe create a > plan on how to fix things, so they could be eventually removed at some > point. > > In any case I would like to find a new home for these scripts, so they > don't "block" other work on initscripts package. And if it would turned out > we can't remove those scripts yet, at least to do some cleanup in those > scripts if possible. Why take the pain? What is to 'fix'? =-=- This approach is an: 'let's break stuff, and then fix some of it, eventually, maybe, to the extent we identify it' IF there were TDD ASSERT testing in place, it might be possible to locate some of the frammage -- but this is not anything like where the Fedorproject is If you wish to 'clean out' initscripts, migrate the content into the relevant bash, and tcsh packages, and be done with it -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
/etc/profile.d/lang.sh -- still needed?
On Mon, 14 May 2018, David Kaspar [Dee'Kej] wrote:
> does anybody know if the files /etc/profile.d/lang.{csh,sh} are still used
> these days, and what for?
by their terms, they are a collection of I18N and environment
settings.
> Do we still need them in Fedora?
Are you asking if /bin/sh, and /bin/tcsh are still installed
or used? I certainly install ande use each
> Should they be installed by default these days?
One assumes the files could be moved out to 'bash' and 'tcsh'
packagings, if the (unstated) goal is to eliminate
'initscripts' as a standalone package
-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Thu, 3 May 2018, Tomas Orsava wrote: > pip actually checks if ~/.local/bin is on the PATH and prints a warning if it > isn't. But nobody predicted that ~/.local/bin might be on the PATH but only > behind /usr/bin. That breaks the intuitive expectation that things installed > closer to the user should take priority. Python works like that. It is easy to get into a bike-shed painting contest about what is and is not 'intuitive' But there is also the expectation of 'least surprise' in a Unix (tm) culture, and I think it is rather without question that: PATH is initially set by conscious design at deployment, and have NOT included per user variations as a default as a matter of 'how we got here' By convention additions to the path come LAST in priority, because of well known privilege escalation attack approaches (the incautious admin sits down at a 'trapped' nominally sick workstation, and fails to use a fully qualified path to 'su' or 'sudo' , or omits to add the '-' to cause PATH cleansing). Incautious admins do this do this once, git bitten, and learn their lesson to use fully qualified paths on workstations, on in accounts, they do not control. I _understand_ that there are lots of ways to seek escalated privileges in *nix ... But do we really need to be adding MORE, and hidden ones with: a. 'breaks expectation' early in the PATH precedence? b. 'invisible' directories in the PATH Local convention here is a ~/bin/ directory, and I think this is a widely observed one I understand the assertion that 'the next new thing' may well have lurked unread and unimplemented, and not been widely implemented until recently, adding: ~/.local/ - or - ~/local/ But defaulting to this needs to be generally accepted, detailed in Release Notes, well communicated, and easy to revert out. It is NOT something that one user asking for it, and an XKCD cartoon should drive I would suggest this is a major change, and needs Fedoraproject Council 'buy in' as to a plan for change, rather than simply being imposed by fiat -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Nagios "disabled" at startup, after recent update
On Wed, 18 Apr 2018, Stephen John Smoogen wrote: > > > > bug numbers? > > Variants on a theme: > https://bugzilla.redhat.com/show_bug.cgi?id=1426816 > https://bugzilla.redhat.com/show_bug.cgi?id=1517925 thank you -- Russ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Re: starting services in fedora
On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote: > The use case is that for simple packages, it's simpler for the user > if the service is available immediately. My initial example with gpm > is actually good here: do "sudo dnf install -y gpm", move mouse, voilà. > Also the case from https://bugzilla.redhat.com/show_bug.cgi?id=1545027: > a user installs some daemon for smartcards, and expects it to be > functional without rebooting. pcsc-lite is an example with a poor history set of interaction with the systemd and itself in a 'no card present' state I've been bitten by that Heisenbug before [1], and was basically told to put black tape over the warning light on the dashboard -- Russ herrold 1. https://bugzilla.redhat.com/show_bug.cgi?id=1046685 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: starting services in fedora
On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote: > > i could puke everytime something is pulled as dependency and started > > without any use > > Can you give an example of such services? The first is a list of 'sbin' processes running from that machine being probed The second are those not sought to be installed by our design, nor to be enabled. remote iscsi support is not anywhere close to the use case for this class of machine, but was included -- Russ herrold [root@pl085086017 ~]# ps afx | grep sbin 257 ?S
starting services in fedora
On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote: > Services which are subject the guidelines allow to be enabled by > default should be such that starting them briefly should not cause > any permanent effects. Some 'real world' data, from a unit that was deployed this morning at 2018-04-17 10:30:17 VM Created herr...@owlriver.com New VM ordered This email sent at 1623 Last failed login: Tue Apr 17 16:22:11 EDT 2018 from 61.177.172.63 on ssh:notty There were 1354 failed login attempts since the last successful login. [root@pl085086017 ~]# so about 6 hours and 1354 probes -- 200 an hour on average That 'window' of open-ness to probers, except for the fact that we blow in 'keyed access only' late in the install process by automation, would not constitute: starting them briefly should not cause any permanent effects I think it proposes to needlessly exposes a unit in an un-patched state, to being taken over -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: starting services in fedora
On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote: > Services which are subject the guidelines allow to be > enabled by default should be such that starting them briefly > should not cause any permanent effects. 'should not' is not true to fact in the real world I mentioned we inject a SSH root key for management purposes. This is a sample of the 'back-splatter' I get all the time Starting the ssh service generates several keys, which then get 'picked up' off host by our control units. I have to have specil code to address the need to go in and eradicate such all the time. Sample below Apr 16 19:22:19 secure PMMan[2423]: PMMan (VM Management) [system@localhost:vm_34458] -- VM setup sees a listener on port 22/tcp Apr 16 19:22:19 secure vm_setup[1331]: ssh: connect to host 10.85.86.17 port 22: Connection refused Apr 16 19:22:19 secure last message repeated 3 times Apr 16 19:22:19 secure vm_setup[1368]: @@@ Apr 16 19:22:19 secure vm_setup[1368]: @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ Apr 16 19:22:19 secure vm_setup[1368]: @@@ Apr 16 19:22:19 secure vm_setup[1368]: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Apr 16 19:22:19 secure vm_setup[1368]: Someone could be eavesdropping on you right now (man-in-the-middle attack)! Apr 16 19:22:19 secure vm_setup[1368]: It is also possible that the RSA host key has just been changed. Apr 16 19:22:19 secure vm_setup[1368]: The fingerprint for the RSA key sent by the remote host is Apr 16 19:22:19 secure vm_setup[1368]: 28:1c:dc:5e:26:9d:4b:1f:2c:a8:aa:8d:42:4f:5f:ea. Apr 16 19:22:19 secure vm_setup[1368]: Please contact your system administrator. Apr 16 19:22:19 secure vm_setup[1368]: Add correct host key in /root/.ssh/known_hosts to get rid of this message. Apr 16 19:22:19 secure vm_setup[1368]: Offending key in /root/.ssh/known_hosts:325 Apr 16 19:22:19 secure vm_setup[1368]: Password authentication is disabled to avoid man-in-the-middle attacks. Apr 16 19:22:19 secure vm_setup[1368]: Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks. Apr 16 19:22:19 secure vm_setup[1368]: reverse mapping checking getaddrinfo for pl085086228.domain.lan failed - POSSIBLE BREAK-IN ATTEMPT! Apr 16 19:22:20 secure pmmanLog[2432]: pmmanLog ( | _event_id: 5 | _owner_id: 0 | _vm_id: 846 | _message: VM setup is shutting down for initial clean backup | _admin: NULL | _thread_id: NULL | _level: I | _viewable: 0 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: starting services in fedora
On Tue, 17 Apr 2018, Samuel Sieb wrote: > I would assume that services that require configuration > before being useful would not be enabled by default. I thing this is a mistaken assumption, and that we are moving into matters of sysadmin taste The SSHD is enabled by default, and likely to remain so We pre-inject a management key for root in a %post stanza of an install, but we still need to go in and add restrictions to keyed access only, down in /etc/sshd/ and IP range lockdowns The Rsyslogd is enabled by default, but has essentally useless default settings -- no Mark service, no UDP listener, local host loggin only -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Nagios "disabled" at startup, after recent update
On Tue, 17 Apr 2018, Stephen John Smoogen wrote: > We have been getting a couple of reports of this, but I have not been > able to duplicate it on my test systems. bug numbers? As I said in my earlier post, there was a new strictness in the nagios parser, and I needed to tighten things up in my config files, before it worked again. I made _no_ 'enable' re-enablement, however -- Russ herrold ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Re: starting services in fedora
On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Apr 17, 2018 at 12:41:15PM -0400, R P Herrold wrote: > To make this work, we could either require that maintainers of A add > Requires(post): B, or delay the starting of services until the end > of the transaction, using a transfiletrigger. This second approach > is much more attractive. Actually we already od a delayed > 'systemctl daemon-reload' after the transaction, and we could start > the services after that. Thank you ... but: you trimmed off and did not respond to the harder part of my real-world example herrold earlier: > I know I need to go in and manually create and add files > like: >/etc/systemd/system/var-ftp-pub-nfs-mirror2.mount > > and then link in that file in: > /etc/systemd/system/machines.target.wants/ > > to get NFS working as I want -- I cannot imagine that** any > ** install tool knows how to read my desires as a deploying > owner which in this case is a RO NFS mount of a third party SAN device, and which contains site specific matter needed for an install needs to access to be useful There are companion files, such as one with a RW: /etc/systemd/system/home-nfs.mount and more, and the RW case is much 'harder' to solve (rootsquash, NFSv4, restricted IP ranges, more). This is for a workstation class unit How is chasing down a rabbit hole of unknowable configuration possibilities, to start things during deployment, and before hardening even vaguely 'solveable' even with unlimited ** packager ** effort? Augeas sort of tried to do this, and got mired in complexity quicksand. Trying to enable install time startups is in no way a 'costless' decision and adding new and ill-defined 'requirements' for unclear reasons will tend to reduce packager willingness to participate As I pointed out, install order matters, and in testing alone, the big O() complexity testing matrix explodes at a O(N^M) rate. That is, it is simply untestable in very short order And just WHY do we want to start services during deployment, and before hardening? Why would we WANT to enable services _before_ application of potential security updates recognized and released after a media freeze? Setting up the firewalld, particularly with the demise and eradication of host name based resolution wrappers, is not an install time task at all, other than 'deny all but ssh' I do not understand the use case at all -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: starting services in fedora
On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote: > > That said, maybe Fedora's service preset files these days are > > carefully enough written and already formalize such deliberation? > > Pfff. Yes they are. See > https://fedoraproject.org/wiki/Packaging:DefaultServices. Is packager install sequencing aware of all of the various systemd dependency resolution qualifications? Wants After Conflicts WantedBy (there are a passel more) I know I need to go in and manually create and add files like: /etc/systemd/system/var-ftp-pub-nfs-mirror2.mount and then link in that file in: /etc/systemd/system/machines.target.wants/ to get NFS working as I want -- I cannot imagine that** any ** install tool knows how to read my desires as a deploying owner -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
batched periodic updates with security 'fast-tracked', vs incumbent continous updates firehose
I see the ongoing disagreement as to approaches in the Fedora FESCO bug, Adjust/Drop/Document batched updates policy [A], and here. I think there is some ** common ground **, fairly easy to implement, to satisfy both the: 'we need testing at once' cohort, and the: 'we are bandwidth constrained, or _churn_-adverse' group I chipped in briefly in today's FESCO meeting, but wanted to state a clean possible away forward Background: For updates, repodata is made by recursing a binary RPM tree That binary RPM tree may contain matter which has been indicated as security sensitive, and the rest not so designated Why not: 1. Continuously add to the binary RPM corpus (the present practice) 2. THEN run a new post process, where a new directory (call it 'security' for the moment) is created via 'hardlinks' (so no additional space requirements) (new) 3. If a given package is 'tagged' as security sensitive (put to one side for a moment HOW to know), add a hardlink to that new directory (new) 3a. Once the process is complete, run a 'repoclosure' test on the 'security' directory, and additional hardlinks to satisfy needed dependencies for those files, pulling from 'base' and 'updates' (similar to present practice) 4. Run a 'createrepo' on the 'security' directory, and name the output something distinctive: security-YMD comes to mind (new) 5. Once a week for say, Tuesday, run a 'repoclosure' test on the FULL directory (the present practice, but with a new output name in a moment) 5a. Raise an exception if it fails such, and bail and carp (the present practice) 6. If it passes, then run a 'createrepo' on the 'security' directory, and name the output something distinctive: patchTuesday-YMD (new) 7. Push those two sets of repodata out async, or daily, under the names (symlinks work here): security (new, so 'security' is always as fresh as possible with repoclosure) 8. - and - ONLY weekly, update the link an updated last successfully generated: patchTuesday (new) [This has the effect of fast-tracking security matter, and yet still having a pointer to the last known good complete transaction set of general updates] === 9. Continue to run 'normal' repoclosure, and 'createrepodata' processes. This is the full and continuous async 'updates' archive (the present practice) === 10. Amend the yum.conf offerings to have reference, in addition to 'updates', enabled and pointing to two new stanza's in 'updates' called: security -and- patchTuesday (new but fully backward compatible) === Use case narrative: If one enables both regular 'updates' and the 'security' / 'patchTuesday' config file, one gets continuous updates. If one disables regular 'updates' , one still gets updates, but only security updates get fast-tracked. If one disables the new stanza, one assumedly does not mess with 'updates' if one cares about updates (so: new, but fully backward compatible) -- Sidenote: Above, I put to one side how to ascertain that something is: 'tagged' as security sensitive I would suggest that if an update is asserted to be security sensitive, just add to the top Changelog entry: a tag with a "[CVE -]" reference, or once any embargo has passed, a tag with a "[Security]" reference and a pointer to the long form description of the issue in play It is trivial to extract the --changelog first stanza from a package, and so scan it and branch accordingly, if such are found, in building the 'security' hardlinked working copy -- Russ herrold A. https://pagure.io/fesco/issue/1820 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
unproductive finger pointing; was: Re: Broken system upgrade due to rich dependencies
On Thu, 8 Mar 2018, Nicolas Mailhot wrote: > That tells a lot more about USA operators being not willing to work with > non USA operators than anything else. ehh? from the headers in that post, as received by me: X-Authentication-Results: bastion01.phx2.fedoraproject.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=laposte.net header.i=@laposte.net header.b="EPfsBz5c" -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Broken system upgrade due to rich dependencies
On Wed, 7 Mar 2018, Nicolas Mailhot wrote: > It is quite insane, that, to this day, users are expected to know the > rpm stack better than dnf, and tell it to update it first. > > KNOWING THE PACKAGE INFRA STACK STACK IS THE INSTALLER JOB > > whenever dnf hits a repo with an updated rpm stack, it should update the > system rpm stack to this updated stack by default in a separate > transaction, before installing anything from this repo. As I recall from RHL days, and trying to do 'hot upgrades' across Major releases [it _could_ be done, but was not time effective], this also pulled in glibc (and kernel pairs in support of that glibc). When such failed, it was time to go to the L0 backup ... and in Fedora and with new deployment automation and configuration orchestration, I suspect few people actually do a reboot, and a L0 backup, before every upgrade. I would expect it to be useful to do the 'subset' upgrade mentioned by Smooge for rpm and friends, _most_ of the time, but occasionally (thinking here of an underlying DB version bump and rebuild by RPM) not always Perhaps scanning the transactionset, add a check and consult an optional: - enable doing updates piecemail flag. If adding such a flag, I'd also add flags for potentially 'dangerous' transactions: - warn me to take a L0, - reboot first, and - reboot after a new kernel, glibc, or rpm -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gate failures
On Mon, 5 Mar 2018, Randy Barlow wrote: > On 03/03/2018 11:15 AM, Michael Cronenworth wrote: > > * F27 Wine 3.3 > > - "The update can not be pushed: no test results found" > > - https://bodhi.fedoraproject.org/updates/FEDORA-2018-fa6f017315 > > * F26 Wine 3.3 > > - "The update can not be pushed: 1 of 2 required tests not found" > > - https://bodhi.fedoraproject.org/updates/FEDORA-2018-c5a0e704d6 > > Both of these seem to have failed rpmdeplint, which I believe indicates > that they are missing dependencies. Coes not this rather imply that the ** test environment ** needs to be well enough stocked to perform tests? It MIGHT be all right to add a BR for each package, but fixing ONCE by stocking the test environment with a test time tool (/usr/bin/rpmdeplint), only, and socumenting what one may count on being present, seems much more straightforward I must confess also that I don't see that a BR actually would persist over into the test harness environment -- russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
python2 dummy packages for EPEL
On Thu, 25 Jan 2018, Jason L Tibbitts III wrote: > Following my proposal in > https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages which > met with favor from a number of folks, I went ahead and set up four > dummy packages: > > python2-setuptools (in EPEL6) > python2-sphinx (EPEL7) > python2-pytest (EPEL7) > python2-six (EPEL7) As a local convention, I customarily _name_ packages which exist ONLY to satisfy a 'provide' : dummy-packagename and add a provide inside. So named, of course, so that they 'jump out' as dummy placeholders See, eg: ftp://ftp.owlriver.com/pub/mirror/ORC/dummy-xscreensaver/ where I needed to satisfy 'xscreensaver' for an in satll of several hundred diskless LTSP units, which were were burning up network needlessly -- Russ herrold ___ 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: EPEL support in "master" branch (aka speeding up Fedora development)
On Mon, 22 Jan 2018, Tomasz K?oczko wrote:
> [tkloczko@domek SPECS.fedora]$ (for i in centos ; do echo -n "$i "; \
grep '%{?'$i * ; done) | grep -v "rhel specific macros"
> ceph.spec:%if ( ( 0%{?rhel} && 0%{?rhel} <= 7) && ! 0%{?centos} )
> ceph.spec:%if ( ( 0%{?rhel} && 0%{?rhel} <= 7) && ! 0%{?centos} )
> cockpit.spec:%if 0%{?centos}
> container-selinux.spec:%if 0%{?fedora} || 0%{?centos} || 0%{?rhel} > 7
> cri-o.spec:%if 0%{?centos}
> docker-latest.spec:%if 0%{?fedora} || 0%{?centos}
> docker.spec:%if 0%{?centos}
> godep.spec:%if 0%{?centos}
> pdc-client.spec:%if (0%{?rhel} && 0%{?rhel} <= 6) || (0%{?centos} &&
> 0%{?centos} <= 6)
> php-libvirt.spec:%if 0%{?rhel} == 7 && 0%{?centos} == 0
> rear.spec:%if %{?centos_version:1}%{?fedora:1}%{?rhel_version:1}0
> resource-agents.spec:%if 0%{?fedora} || 0%{?centos_version} || 0%{?rhel}
> runc.spec:%if ! 0%{?centos}
> skopeo.spec:%if 0%{?centos}
> strace.spec:%if 0%{?fedora} >= 20 || 0%{?centos} >= 8 || 0%{?rhel} >= 8 ||
> 0%{?suse_version} >= 1300
> vdsm.spec:%if ! 0%{?centos}
you may wish to add a:
| awk -F: {'print $1'} | uniq
I am not quite sure what point you are trying to make -- in an
'ad hoc' local collection of a bit under 2000 .specs, I turn
up an additional match:
[herrold@centos-7 SPECS]$ (for i in centos ; do echo -n "$i "; \
grep '%{?'$i * ; done) | grep -v "rhel specific macros"
qpdfview.spec:%if 0%{?centos_version}
qpdfview.spec:%if 0%{?centos_version}
rear.spec:%if
%{?centos_version:1}%{?fedora_version:1}%{?rhel_version:1}0
[herrold@centos-7 SPECS]$
and very curiously as to 'strace' in your list, of course
there ** is no **
'0%{?centos} >= 8
nor a released rhel at that number either ;)
We might speculate, given the component ('cockpit' and
'strace') it relates to that internal candidates inside RHEL
engineering that find using that number '8' useful, however,
for doing development
I am presently standing for the elected office on 'council',
and really part of my 'platform' locked in last November of
December was working at 'healing' the fissures between Fedora
and EPEL
I do not see that the rapid fire posts in which you have
engaged in the last few days really _help_ that goal, but
rather they seem strident and divisive, and seem to make
harder such 'healing'
-- Russ herrold
___
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 Sun, 21 Jan 2018, Tomasz K?oczko wrote: > If it is common in case of EL7/EL6 EPEL packages consumers it is perfect > reason to not bother EPEL on master branch because Fedora has noting out > from such end users and keeping all EL6/EL7 adjustments are only slowing > down Fedora development by making specs less readable. Tomasz Do you have statistics about the number of packages 'migrating' from Fedoraproject to RHEL, vs the number of EPEL packages doing the same It is all well and good to have a fast moving playground environment, but some (and particularly, I) actually use both as sources for solving needs of paying customers and EPEL, for me, is the more fruitful one from which to build solutions on top of CentOS (and not Fedora's more short lived, properly 'not concerned' about long term supportability offerings) -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Rename "nobody" user
On Thu, 11 Jan 2018, Lennart Poettering wrote: > We are not taking the concept of this user/group away. We are also not > taking the UID/GID assignment 65534 away, either. All we are doing is > assigning it a better name and do so unconditionally, independently of > whether nfsutils is installed or not, as the UID/GID 65534 has plenty > uses outside of NFS. fixing something well and extensively documented, to something 'new and improved' in the face of a huge and unchangeable set of implementations (and third-party webbish documentation) that cannot be changed: RO media off-line images backups iscsi targets NFS exports from third-party appliances interop in hetergoneous environments SMB ... is this really worth the effort? All it does, like the XKCD 'N+1 standards' cartoon, is add one more 'standard' that cannot displace the incumbents and diverges from 'Unix' for an, at best, cosmetic reason, as you state: All we are doing is assigning it a better name ... -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Glibc collation update and sync with cldr
On Fri, 5 Jan 2018, Rafal Luzynski wrote: > be the same as the default "C" locale or slightly different. I'm not > aware of any Fedora package where the order of the config files does > matter apache cares in /etc/httpd/conf.d/ with virtual host enablement on ports along with multiple vhosts udev does in /etc/udev/rules.d/ notwithstanding a convention of doing manual application order with leading digits Indeed an undocumented switch mid release in RHEL 7 from a 'ls' type enumeration of a single directory, to a 'find' one not constrained by '-maxdepth' causes us some heartburn, as we previously had 'stashed' un-used initscripts ?? I fergit ?? down in /etc/sysconfig/network-scripts/attic/ that were mysteriously being applied. Not sort order related on the last, but still, I would tread lightly here -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Firefox "Looking Glass" fiasco
On Mon, 18 Dec 2017, Chris Adams wrote: > the requires downloads to be useful. I think simply requiring Mozilla > to change their policies is unacceptable, as this still depends on a > third party to properly enforce such policies (and not have any security > issue that could result in untrusted addons being installed). > > IMHO such behavior needs to be disabled by default in any packages > shipped by Fedora for Fedora to remain a trustworthy distribution. 'Electrolysis' was a Mozilla.org codeword for a sub-project enabling in an A:B sample, 'telemetry' -- that is keystroke logging, click monitoring, timing, and more, largely without prominent external notice. I had a performance issue related to inter-tab communication in a restrictive environment I run Firefox in, along with SElinux denials, and spent some time 'running down' several problems, in the early summer see: https://support.ant.com/hc/en-us/articles/115000513446-Firefox-51-Multi-Process see my bug: https://bugzilla.redhat.com/show_bug.cgi?id=1473754 upstream as well https://bugzilla.mozilla.org/show_bug.cgi?id=1383141 closed into: https://bugzilla.mozilla.org/show_bug.cgi?id=1376559 https://bugzilla.mozilla.org/show_bug.cgi?id=1129492 because SysV shared memory follows Unix's “same uid policy” and can't be restricted/brokered like file access. (It was observed when the initial attempt at a desktop content system call whitelist was made, but that was long enough ago that there could have been significant changes to how graphics work that might make this not a problem, so this should be double-checked.) There's a not-well-specified revision to use memory-mapped files (http://patchwork.freedesktop.org/patch/15082/) but I don't know what would need to happen to make it work — Ubuntu 14.04 has a new enough X server and should (I think?) have new enough libraries, but X clients still empirically use SysV (including the Firefox parent process). see also this: https://mjg59.dreamwidth.org/42320.html which implies a shm IPC privacy approach exists, but is not implemented. It ignores adding SELinux constexts, and so the unhopeful conculsion he draws may have been overtaken by events https://bugzilla.redhat.com/show_bug.cgi?id=1188290#c1 There was a related SELinux / no '--no-xshm IPC' filing upstream as well, which I cannot lay hands upon atm. It looks like others have noticed the 100 pct usage, and IPC problems as well https://bugzilla.redhat.com/show_bug.cgi?id=1471149 One had to notice such exfiltration of data, and go looking for how to turn it off. I did by watching squid logs of queries, seeing expected domains, and then going looking. Adding a prefs.js with // browser.tabs.remote.autostart = false browser.tabs.remote.autostart.2 = false // // ... above silently set itself true again 2017 08 29 // 52.2.0 (64-bit) ESR // Centos 7, 2017 09 update is: 52.3.0 (64-bit) was supposed to work, but it turned out that some process inside FF was able to over-ride and un-restrict such even when explicitly turned on. I had to change ownershop of the configuration file to root.root from userid.blah to stop that nonesense I start ff inside a 'ssh to a unpriv'd uid' localhost X forwarding tunnel -- it breaks sound and video, but ... * shrug * I'd rather not have data I care about being exfiltrated I believe Jan Horak inside RH does something similar https://bugzilla.mozilla.org/show_bug.cgi?id=1129492 'it looks like the Firefox over ssh is not used by masses' -- Russ herrold === PEFF -- Privacy Enhanced Firefox invocation ... privacy enhanced, isolated userid firefox invocation startup PATH: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/home/herrold/bin reduced path PATH: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/home/herrold/bin current id: uid=500(herrold) gid=500(herrold) groups=500(herrold),10(wheel),135(mock),498(pulse-access) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 PEFF: ghola note: ghola is a non-priv'd user on localhost, [H/T: Frank Herbert] which we access via a keyed SSH connection to try to avoid some content exfiltration by hostile web browser applications: Firefox, Flash, etc THISHOST: centos-7.first.owlriver.net start: Mon Dec 18 09:45:31 EST 2017 Command: ssh -X -4 -l ghola centos-7.first.owlriver.net export ` dbus-launch ` ; firefox --no-remote -- now down in the limited, privacy enhanced firefox userid reduced path PATH: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/home/ghola/bin current id: uid=606(ghola) gid=606(ghola) groups=606(ghola),498(pulse-access) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Command: umask 022 ; /usr/bin/firefox --no-remote -- ___ devel mailing list --
Re: Trying to contact developer Axel Thimm
On Wed, 13 Dec 2017, Stephen John Smoogen wrote: > On 26 October 2017 at 19:13, R P Herrold <herr...@owlriver.com> wrote: > > On Fri, 27 Oct 2017, Michael Schwendt wrote: > > > >> twitter users could try @athimm > > > > I already sent a .@ message to that account no twitter reply seen here > Did anyone receive a reply back from Axel on this? as the mail-load issue presents itself and is detected, it seems fair to add a process to devnull when email rejects go over 5 days lag, and drop a note on the FAS for that account Possibly also flag for a 'no longer active' maintainer' review -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to I have to do....
On Sun, 10 Dec 2017, Graham Leggett wrote: > In this case, we have the needs of the Fedora project (this > change) stacked up against your needs (your reluctance to > perform a task). This line of argument is a 'straw man' as are several other rationalizations advanced for NOT giving effective notice. As I read the thread, Steve has never said he was 'reluctant' nor that he was unwilling to make changes, but rather he said that he was troubled when PP changes 'get dropped on him' as maintainer without effective prior indication that there is an issue The bugzilla, and tracking bugs, and Blockers and Depends are just not that hard to use. Much automation in this regard exists -- FTBFS, etc -- bugzilla had an API for just such a purpose The proponents of simply making a change and letting the maintainer take his luck, seem to think that using the tracker and the overhead of opening bugs would cause load would go up I doubt it would turn out that way; This is almost certainly not the case. If a maintainer gets a notification via a bug filing that some 'Future Feature' change is needed, and there is a pointer in the parent bug as to the 'why' and the approach to modify matters, I have to think that the proposed will get applied next update round, and BY THE MAINTAINER, and the dependent bug closed through the release automation And where there is an impediment -- there was one on the font removal matter 'blasted through' by a PP, and if asked, as in a bug, the maintainer would so indicate, in such a case, probably in the dependent bug. He promptly did so for me, when I asked directly If filing bugs, and mostly having maintainers respond and make changes does not work, why then the Fedoraproject model of self-selecting volunteers maintaining packages is broken, and Red Hat employees (which, if one examines the poster's employer, is who want to 'parachute in' and use PP rights, in the first five cases I checked) should simply do all the commits > The needs of Fedora must win in this case. The predicate was a straw man based on facts not present in this thread --- 'must win' seems to overstate the case. Why then even bother to have process? Let it all hang out and anyone commit as one will. Well, this turns out not to work, as we tried this with release three of the post RHL cAos project, long ago, and got a royal mess with such a lack of process ... > Given your email address, I am going to assume you’re paid > by you’re employer to work on Fedora, and are not working on > Fedora by your own volition. This is the time when your > mentor should step in set some of the ground rules for how > you interact with a community. so, now, an 'ad hominem' attack in rhetoric as well? So much for 'being excellent' to one another -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to I have to do....
On Thu, 7 Dec 2017, Yaakov Selkowitz wrote: > https://fedoraproject.org/wiki/Provenpackager_policy > These were properly announced: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/ > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/ That section provides in relevant part: > Provenpackagers should try to communicate with owners of a package in bugzilla, irc or email prior to making changes IMHO, A general email to a high traffic mailing list is insufficient IRC is even worse for notification Absent some pressing need (which was NOT present here -- this was just 'distribution housecleaning'), this was insufficient notice on a non-urgent matter, to my thinking I have filed a FESCO bug on the topic, with proposed revised language: https://pagure.io/fesco/issue/1799 -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Reduce Initial Setup Redundancy
On Mon, 4 Dec 2017, Chris Murphy wrote:
> >> === Root Account ===
>>> group. We will remove the root password creation spoke.
>>> All Workstation installs will have no root password set by
>>> default, as in Ubuntu. Having a root password is not
>>> useful for nontechnical users, and it is confusing to ask
>>> users to create multiple passwords
If this is a communication problem, why remove a password,
just remove the spoke?
Set _some_ DRP password, deterministically to an unguessible
value, and save that value in a well-named file on the root
volume
# umask 077
# date +%s > /root-passwd.txt ; ( head -n 1 /root-passwd.txt ; \
lvdisplay | grep -i UUID | rev | awk {'print $1'} | rev | \
sort | head -n 1 ) | md5sum >> /root-passwd.txt
... and set the root password to the value of the last line of
/root-passwd.txt
An interested user may:
1. note it for a rainy day
2. change it to taste and rm the file
A disinterested user may ignore it
A person to whom the user takes a 'sick box' can use recovery
media tool, loop moount a balky drive, and read the file to
note the credential, and then boot down into a recovery mode
with the needed credential
> Also, for any kind of early boot troubleshooting even once a user is
> created, systemd emergency and rescue targets only accept root user
> login. If root user is disabled, it's impossible to do such early boot
> troubleshooting. So I think systemd needs a way to accept an admin
> user (wheel group) as an alternative login rather than only root.
I really dislike adding a new 'secret way to crack into a box'
and the complexity it would add to systemd, and auditting the
same, a lot more than I dislike leaving a cleartext file with
a complex password.
And of course this does not come anywhere a secured grub
bootloader discussion, nor LUKS, and clevis and tang ;)
-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: request admin access for gnumeric
On Mon, 20 Nov 2017, Jason L Tibbitts III wrote: > But we don't do per-branch privileges. So either you have commit > privileges on all branches, or you don't. > > Perhaps you could include some details about what leads you to believe > that you have privileges on one branch but not the others. I have formerly looked at: https://admin.fedoraproject.org/pkgdb/package/nagios/ which (seemingly) had per F and EPEL release specific differing commit permissions and also which does not shows rights that I know Smooge added last week. The bug red notice does not indicate this information is stale, but only that a packagedb was stale ... One now assumes tht more detail is needed to ovver a (optionally per package) redirection Taking your URL as a 'crib', and looking at https://src.fedoraproject.org/rpms/nagios I see the expected data -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Deprecating old networking protocols
On Tue, 14 Nov 2017, Steven Whitehouse wrote: > I think it is probably overdue in the DECnet case, however I > did get a very happy with it for the most part. Anyway it is > clear that nobody is maintaining it and it seems sensible > that it should get removed unless someone with sufficient > time wants to step forward. That has not happened so far, I still have customers with Decnet in production (certain medical lab equipment 'just works' and uses the transport); until those units die, there will not be sufficient motivation on the customers' parts to spend the money to replace it (and at that time, a technology refresh will happen as well eyeglass labs, and colonoscopy testing, primarily The 'network' for units are physically isolated, and indeed, occasionally accessed only via a graphical terminal emulator such as VNC, facing into a TCP/IP network on a second interface. No need for updates here -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: ansible1.9 package
On Tue, 7 Nov 2017, Mátyás Selmeci wrote:
> This highlights a problem I've occasionally had with EPEL, namely that
> packages I depend on occasionally get removed. This especially causes trouble
> when a package gets removed because it's now in RHEL, because it takes a few
> months for CentOS and Scientific Linux to update. Perhaps you could create an
> 'epel-unsupported' repo and move packages there instead of removing them?
As others have suggested, running a private mirror of (at
least) the SRPMs and learning how to build them, or a larger
mirror including binaries, and optionally locally
'[re-]signing' them as Smooge mentioned {nice trick, btw,
smooge} comes to mind. I don't have to fiddle with the
underlying scripts except to add new point releases (of
CentOS), and less frequently, of EPEL
People have tried over the years to put together busineses
(Progeny, me) or community projects (Fedora Legacy), but
economically finding the paying customer mass (and it may well
not exist) is not there to justify doing that as a 'full time'
occupation, so it rather becomes an adjunct to consulting when
custom building, ports, and back-ports
for i in lftp-epel-6.conf lftp-epel-7.conf
lftp-epel-testing-6.conf lftp-epel-testing-7.conf ; do
NONCE=` grep -v ^# $i | tail -n 1 ` ;
du -sh ${NONCE} ; find ${NONCE} -type f | wc -l ; echo "" ; done
11G /share/MD0_DATA/Mirror/redhat/epel/6
5966
17G /share/MD0_DATA/Mirror/redhat/epel/7
6534
709M/share/MD0_DATA/Mirror/redhat/epel/testing/6
391
2.3G/share/MD0_DATA/Mirror/redhat/epel/testing/7
953
... I have a bit north of 750k SRPMS in my local archive and a
suite of tools to handle that porting and back-porting
developed over ... almost 20 years ... goodness
-- Russ herrold
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Re: Remove old GPG keys?
On Tue, 31 Oct 2017, David Cantrell wrote: > I don't really consider this a thing about saving space or making the > output of 'rpm -qa' look nicer or something, but rather being good users > of GPG. As noted but not addressed, which keys actually have been signed at GnuPG key-signing WoT 'parties? Which are presently on the public key-server constellation? The answer: Of the 38 keys on: https://getfedora.org/keys/ and https://getfedora.org/keys/obsolete.html ZERO are -- one (0xF5282EE4) seems to be a collision artifact [1] > If we create and then phase out signing keys, then part of > our process should also involve sending revocations for the > old keys. but the ** private keys ** were never released or public anyway ... Revoking a ** public key ** (which is the keys in the RPM db in discussion) is useless as all it permitted doing was (and is) verifying that a proper private key existed at a place and point in time to sign that package. It is EPEL (thus at least one part of fedora) practice to do so already > And that process could be automated by a dnf plugin too. > Leaving old keys around on the system for verification > purposes presents a risk should the old key become > compromised. so shred the HSM holding the private key ... This thread is time wasting and posturing -- Russ herrold 1. the audit script is at: http://gallery.herrold.com/stuff/harvest-keys.sh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Remove old GPG keys?
On Tue, 31 Oct 2017, David Cantrell wrote:
> > # rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"|wc -l
> > 64
>
> Do we issue revocations for old keys? If not, let's do that and extend
> dnf to honor those and clean up?
What is the 'use case' for potentially preventing installation
against a already know key of a existing, but older 'noarch'
package; or one unpacking an older SRPM and NOT getting the
scary NOKEY warning? The size of the keys is trivial, even
though they do tend to accrete in a 'long running' instance
heck, I'll wager mostly those keys are never countersigned
into a web of trust, and sent to the constellation of GnuPG
key-servers in the first place
Going even further, and revoking the keys is 'fly-specking'
overkill
I have no problem with removing keys not _used_ on a given
host (such information being able to be compiled out of the
RPM database)
-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /bin/sh and lua; was: Re: common location of spec files in upstream sources
On Fri, 27 Oct 2017, Jason L Tibbitts III wrote:
> >>>>> "RPH" == R P Herrold <herr...@owlriver.com> writes:
>
> RPH> I noticed in the Scripts languages section the ** absence ** of
> RPH> /bin/sh (and not 'bash' with its 'bashisms'), and lua
I was referring to: section 37 ("Scripting inside of spec
files ")
https://fedoraproject.org/wiki/Packaging:Guidelines#Scripting_inside_of_spec_files
-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
/bin/sh and lua; was: Re: common location of spec files in upstream sources
On Fri, 27 Oct 2017, Vít Ondruch wrote: > https://fedoraproject.org/wiki/Packaging:Guidelines interesting to re-read I noticed in the Scripts languages section the ** absence ** of /bin/sh (and not 'bash' with its 'bashisms'), and lua Each should probably be present for completeness ... it may finally provoke the lua hooks in rpm to become used, and os useful This may merit some discussion here before I edit the wiki -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Trying to contact developer Axel Thimm
On Fri, 27 Oct 2017, Michael Schwendt wrote: > twitter users could try @athimm I already sent a .@ message to that account -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
common location of spec files in upstream sources
From a survey of about 1700 .spec files in my current working
collection, the overwhelmingly common place to ** install **
such is in a:
%doc
directory
Most simply place them in the top directory, at a depth even
with where a V[ersioned] tarball is unpacked by the %setup
stanza. Then
rpmbuild -ta (package-V).tgz
can un-gzip and find it there and will build to order in
chained automation. I see in my local archive:
bzr/kicad/RCS/README,v:rpmbuild -ta ${PROJECT}-${YMD}.tar.gz && {
which does this. The R[elease] value gets tacked on during
the build process
This is most sensible (I have much automation for
automatic VCS CO, .spec file, and then tarballgenerators,
which substitute in various variable substitutions). See,
eg.,
ftp://ftp.owlriver.com/pub/mirror/ORC/dl/README
of which I was tracking VCS dalies and testing, before it
moved into Fedora
Others use this approaches similar to this as well -- I see
several
'%{_package}.spec.in'
files by others to that effect as well. See, eg.,
krb5-auth-dialog and GeoIP
-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
hp-plugin doesn't work in hplip-3.17.9 - move to 3.17.10 if you need
On Thu, 26 Oct 2017, Zdenek Dohnal wrote: > HP changed website this week, which has consequences for getting hp > proprietary plugin - it cannot be downloaded anymore for hplip-3.17.9, > which is in stable Fedoras (f25 and f26) and Fedora 27. ... > upstream several times about uploading plugin into openprinting.org > website, but without answer (probably because it was available on > hplipopensource.com). That's the situation for hplip-3.17.9. > Luckily, there is hplip-3.17.10 in updates-testing repository, which has > plugin on openprinting.org. So if someone now needs to install printer, > which needs proprietary plugin, please update hplip to 3.17.10 from Not so much luck, as a sufficiently good process mostly being followed ['The more a well designed process is followed and tweaked with improvements, the more lucky one becomes' ;) ] The post partially quoted above points up another benefit from the virtue of 'packaging everything' as discussed in the recent 'packaging ruby dependencies' thread. When an upstream 'goes wonky' for whatever reason (there was a similar example in the Node.js ecosystem where a maintainer took down a minor but critical dependency, and 'broke world'), one can 'fall back' to the last SRPMS (and other VCS backups as well), and recover Without packaged sources, and the discipline of sub-dependency determination and solution, and the 'four freedoms' checking goodness of a formal 'licenses review', and the additional set of eyes cross-checking work, one loses so much -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removing ghostscript-fonts package
On Fri, 6 Oct 2017, Xose Vazquez Perez wrote: > Zdenek Dohnal wrote: > > > I am going to retire ghostscript-fonts package in F27 because its fonts > > are deprecated and replaced by urw-base35-fonts package. I don't see a urw-base35-fonts SRPM in my RawHide ... has it been packaged? My mirror only fires weekly, but it seens ... hasty to retire a package before its successor has 'aged' a bit to let possible bugs appear. In checking the CTAN site, it seems pretty likely that font metrics will have changed and so the appearance of documents will be affected -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: tcp_wrappers deprecation
On Fri, 18 Aug 2017, Jason L Tibbitts III wrote: > Sadly I know how terrible tcp_wrappers is and so I know it needs to go > away. just because crows trying to protect their young will 'mob' a hawk hunting to feed her young does not make the hawk terrible; latest is not always greatest I found the ranting toward wrappers unconvincing years ago - - I remain unconvinced that it is terrible code > It's just unfortunate that there's no replacement for it besides > firewalling, and dealing with the firewall is unfortunately so > complicated. wrappers will invoke the resolver, and do PTR lookups, and so can do: - hostname based, - domain related, and - absent DNS information based blocking I know of no way to do these tasks with the 'firewalld' code -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Mass package change (python2- binary package renaming)
On Tue, 8 Aug 2017, Zbigniew Jędrzejewski-Szmek wrote: > Hello Fedora Python package maintainers! > > This is an announcement of a mass package renaming: > Python 2 binary packages will be renamed to python2-*. > List 1. for those packages which will be taken care of by the mass remaining >Patches: https://in.waw.pl/~zbyszek/fedora/pyrename/ Looking at a sample patch file, it apperas that more than a simple s/python-/python2-/g replacement is being done [1] The patch in question also contains 'tampering' with the %description stanza: -%description -ATpy is a high-level Python package providing a way to manipulate tables of -astronomical data in a uniform way. It provides built-in support for NumPy -recarrays and common astronomical file/database formats (FITS, VO, HDF5, +%global _description\ +ATpy is a high-level Python package providing a way to manipulate tables of\ +astronomical data in a uniform way. It provides built-in support for NumPy\ +recarrays and common astronomical file/database formats (FITS, VO, HDF5,\ and ASCII tables) with a very simple API. +%description %_description + ... this does not seem 'low risk', as substitutions happen form many fields. It is also not mentioned in your post Who shall be expected to repair FTB's after the patch? -- Russ herrold 1. https://in.waw.pl/~zbyszek/fedora/pyrename/ATpy.spec.patch ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Pull request/Changes to CentOS Extras repo??
On Wed, 3 May 2017, Orion Poplawski wrote: > > python3-flask: > >python3-itsdangerous > >python3-sqlalchemy > > again, already in EPEL7 ehh? -- I see no python3-sqlalchemy in EPEL-7 [herrold@centos-7 ~]$ date ; sudo yum -q clean all Thu May 11 12:19:59 EDT 2017 [herrold@centos-7 ~]$ date ; sudo yum -q install python3-sqlalchemy Thu May 11 12:20:04 EDT 2017 Error: Nothing to do [herrold@centos-7 ~]$ sudo rpm -V epel-release [herrold@centos-7 ~]$ -- Russ herrold ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
FESCo, Council, FAmSCo elections - Voting period is now open
On Tue, 8 Dec 2015, Jan Kurik wrote: > The voting machine: https://admin.fedoraproject.org/voting/open There is an obvious 'typo' on that page -- s/Lost/Last/ -- Russ herrold -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[EPEL-devel]Re: TexLive
On Sat, 21 Nov 2015, Germano Massullo wrote: > Did you try to ask them to include all TeXLive packages that are > available from upstream? If not, I can try there are lots of licenses to audit, per sub-package, and dependency trees of matter limited to non-commercial and so forth -- Russ herrold ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel]Re: TexLive
On Mon, 23 Nov 2015, Germano Massullo wrote: > You can simply re use the collection of texlive-scheme-full for Fedora > (non EPEL) One would assume so, but I found dependencies on non-free bits in there -- Russ herrold ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
Re: Trusted Boot in Fedora
On Tue, 28 Jun 2011, Przemek Klosowski wrote: the processor serial number (PSN) wasn't shut down---every post-PIII CPU has it. The access is often disabled by the BIOS, but it's there: http://pcworld.about.net/magazine/1903p198id38601.htm I think that TPC requires that PSN are enabled, but I can't think of why. probably to provide a unique serial number to use as part of the TPM attestation private key generation, to ensure uniqueness and to prevent a replay type attack -- Russ herrold -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's this /run directory doing on my system and where does it come from?
On Wed, 30 Mar 2011, Rahul Sundaram wrote: There are many directories already in Fedora that are not defined by FHS and even though we have asked them to update it (libexec, /selinux /sys etc), there is noone maintaining it. This is stunningly untrue. I've worked for years in the fields of LSB, FHS and LANANA to make sure there are traceable paths for such requests. Post the URLs to your bugs in the LSB / LF tracker if you assert you have done such -- Russ herrold -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ABRT opt-out? (Re: bugzilla bugzappers?)
On Thu, 4 Nov 2010, Christoph Wickert wrote: How would you do that? A popup in ABRT that reads Sorry, but the maintainer of this package has decided to not accept any bug reports. I think this would be a *really* bad user experience. If telling the truth about Open Source development decisions provide a '*really* bad user experience', the packager and the hosting project has to decide if a fork is in order, and if they can credibly do it; or to remove the package and explain why; or if it is such an immensely popular package that one 'CANNOT' omit it [firefox and the Mozilla Foundation's approach on trademarks comes to mind], still document a URL to the problem in the popup on a pre package basis Concealing and hiding from the truth (lying to one-self and others about reality) can scarcely be called 'being excellent to one another' or to the community toard which advocacy and service are being targetted, no? -- Russ herrold -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fast Light Tool Kit
On Sat, 30 Oct 2010, Eric Sparks Christensen wrote: I found a program that I want to package but it requires Fast Light Tool Kit (FLTK). The source is a single file with no readme and I'm not exactly sure how to package the software. Has anyone worked with FLTK that might be able to help me with this? it is packaged abundantly. What is the question? fltk /mnt/nfs/var/ftp/pub/mirror/redhat/rawhide/SRPMS/fltk-1.1.10-4.fc15.src.rpm also in epel and fedora for since forever -- Russ herrold -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
On Fri, 4 Jun 2010, Tom spot Callaway wrote: Matěj Cepl asked for I would really like to see some opinion of the real European IP law on the matter. Does anybody have URL? and received a slam at lawyers in the open to the reply. Matěj, as I'm sure you know, we could find a lawyer who would tell us just about anything we wanted to hear. sad, sad -- Russ herrold -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Worthless updates
On Wed, 3 Mar 2010, Ralf Corsepius wrote: Wait until you will want to address a serious/critical bugfix to a perl-module which carries a dependency on a perl-module you haven't kept in sync with CPAN = You'd have to resort to either fastestly upgrade a series of perl-modules or resort to other solutions (E.g. to deliberately remove versioned dependencies from rpm and try to get away without them.) oh, please -- simply this is simply FUD there; perl module packaging against CPAN is not black art, but merely tiresome in running down sub-dependencies, and reading all the ways the perl folks emit missing dependency and 'optional' ['suggests', 'enhances'] determinations and forks through the lens of the RPMBUILD. ftp://ftp.owlriver.com/pub/mirror/ORC/bugzilla/perl-rpmbuild A trained eye and a minimal bit of work can yield a set of grep based filters to 'see' such trivially; I run rpmbuild, then a local helper wrapper: perl-rmbuild, and can knock out a module in less than 5 minutes to current. I think the deepest chain I have is perhaps 30 modules -- a tossup between an old bugzilla, spamassassin, and zoneminder, and a surprisingly deep leaf target: perl-Net-DNS-SEC -- Russ herrold -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
