[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - Many changes have been made to the Ruby packaging guidelines to reflect the current state of Ruby packaging. * https://fedoraproject.org/wiki/Packaging:Ruby * https://pagure.io/packaging-committee/issue/710 Note that the macros

Re: macro(s) to use in RPM spec for /usr/lib/modules-load.d

> "ES" == Eric Smith writes: ES> What macro(s) should I use in an RPM spec to refer to a directory ES> like /usr/lib/modules-load.d, which is under /usr/lib even if libdir ES> is /usr/lib64? Is there something better than ES> %{_usr}/lib/modules-load.d? It seems that

Re: F29 System Wide Change: Move /usr/bin/python into a separate package

> "SB" == Sérgio Basto writes: SB> Maybe better is remove /usr/bin/python , it will force people fix SB> the path , instead of a silent move . That's just a more extreme version of what is being proposed here. The proposal moves the /usr/bin/python symlink to a separate

Re: upcoming systemd-239 release — call for testing

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> It's either %include or a fairly big copy The first solution ZJ> is awkward, and the second one is ... awkward. But yeah, maybe we ZJ> should bite the bullet and do the copy A bit sad. It shouldn't be that bad. The body of the scriptlet

Re: upcoming systemd-239 release — call for testing

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> rpm does not allow reading that file from the tarball, because it ZJ> wants it to be available for %include when the spec file is parsed. ZJ> That's why I put the in git directly. This one of several reasons why using %include in a Fedora

Re: upcoming systemd-239 release — call for testing

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> That's not an attractive option, because there's so many of them. Ah, so the issue is merely the quantity of scripts. I did check out the package from git and it doesn't seem all that bad; most of what's there is (sort of excessively

Packages with compiled python files outside of /usr/lib*/python8

As part of a recent guideline change (https://pagure.io/packaging-committee/issue/772) which ties in with an accepted F29 change (https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation), this section of the guidelines was overhauled for F29+:

Packages which call install-info in scriptlets

As of Fedora 28, the 'info' package has gained a file trigger (%transfiletrigger) which will automatically rebuild the info directory node when any file is installed into %_infodir. Thus it is no longer necessary for packages in F28 or newer to include scriptlets which call install-info, nor to

Re: Packages which call install-info in scriptlets

> "PP" == Petr Pisar writes: PP> https://bugzilla.redhat.com/show_bug.cgi?id=1592433 I located the bug, which is that fix-info-dir needs to pass an extra flag to install-info; otherwise install-info tries to open the info file to figure out which entries to remove. But of course the info

Re: Packages which call install-info in scriptlets

> "AM" == Andrea Musuruane writes: AM> I think rpmlint should be amended. Now I get "E: AM> info-files-without-install-info-postun" on F28. Yes, rpmlint needs to be told to ignore this issue on F28+. - J< ___ devel mailing list --

Re: Packages which call install-info in scriptlets

> "JJ" == Jerry James writes: JJ> One reason to do this is that the info file does not contain the JJ> entry, so there is nothing to extract. Surely it would be better to fix the info file, wouldn't it? - J< ___ devel mailing list --

Re: Packages which call install-info in scriptlets

> "PP" == Petr Pisar writes: PP> What about uninstallation? That is covered by the existing triggers: %transfiletriggerpostun -n info -- %{_infodir} [ -f %{_infodir}/dir ] && %{_sbindir}/fix-info-dir --delete %{_infodir}/dir &>/dev/null If fix-info-dir is not working as documented (where

Re: FESCo Elections - May 2018 : Results announcement

> "JB" == Josh Boyer writes: JB> I know we do a lot of rubber stamping because process requires it. This is one of the primary reasons why I lost interest in serving on FESCo way back in the day. It felt like an endless stream of feature process documents without much real involvement in

Re: f29 bootloader changes / raid1 installs + efi

> "KM" == Kyle Marek writes: KM> I can't remember what else I discovered in reading the manual KM> last. Do you know if there are any other discovery/identification KM> limitations to the old superblocks? I don't think there are any in the context of having a small RAID1 ESP across not too

Re: FESCo Elections - May 2018 : Results announcement

> "MM" == Matthew Miller writes: MM> That seems like we're doing things right! Yes, of course, one nice thing about Fedora is that if you are willing to do work, people will let you do work. But it also might explain why there is something of a lack of candidates for FESCo. There are

Re: f29 bootloader changes / raid1 installs + efi

> "CM" == Chris Murphy writes: CM> The installer right now, against upstream mdadm dev's explicit CM> advice, sets up an mdadm raid1 using (I think deprecated 0.9 CM> metadata format but could also work with 1.0 format). And I'm really happy that it does; I have used that configuration for

Re: f29 bootloader changes / raid1 installs + efi

> "AL" == Andrew Lutomirski writes: AL> I wouldn't be surprised if using a capsule-on-disk did terrible AL> terrible things if ESP were on invisible RAID 1 (a la mdadm 0.9 or AL> 1.0). Anything that writes will do "terrible" things (really just corrupting one of the copies, which for

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - In Fedora 28 (and rawhide), the texinfo scriptlets (which call install-info) are no longer necessary and should be removed or, for cross-release specfiles, wrapped in conditionals. Note that there are nearly 300 specs currently

Re: Packages which call install-info in scriptlets

Update to texinfo which should fix the problem with info nodes not automatically being removed: https://bodhi.fedoraproject.org/updates/FEDORA-2018-066a9994da Please test and give karma. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: F29 System Wide Change: Hide the grub menu

> "JK" == Jan Kurik writes: JK> 1. Add patches to grub to also make pressing F8 show the menu One thing I've never really understood is the reason for using such a small set of keys to interrupt the boot process. I seem to recall that in older versions (perhaps pre-grub2) the space bar or

Re: F29 System Wide Change: Hide the grub menu

> "JF" == John Florian writes: JF> Does Fedora really have that large of non-technical audience? It's an interesting question, but it seems to me that the answer doesn't really matter. If they're non-technical, the assumption is that they don't want to see the stuff and indeed, what we

Re: F29 System Wide Change: Hide the grub menu

> "CM" == Chris Murphy writes: CM> I think it's to avoid ambiguity. F8 on one of my computers tells the CM> firmware to do a firmware update or some such thing, so I'm going to CM> press F8 and maybe get a firmware update menu, or maybe I'll get a CM> GRUB menu, depending on my timing. And I

Re: F29 System Wide Change: Hide the grub menu

> "AL" == Andrew Lutomirski writes: AL> If the protocol were that the boot menu would be shown if any key at AL> all were held down, then we wouldn't need a 1 second delay. For some reason I also recall just holding shift down to get into grub, and doing searches on that seems to imply that

Re: Hiding the grub menu by default on single OS installs

> "TK" == Tomas Kovar writes: TK> - this one is on the polish side of things: [don't keep bouncing to text mode] I might also add that as part of this, we'd also need to get rid of the very early message about EFI secure boot being enabled. Then we'd be left only with the random kernel

Re: Unified Unison package (again)

> "RWMJ" == Richard W M Jones writes: RWMJ> But wouldn't a single package in fact be preferable, as it'll be RWMJ> simpler than maintaining multiple packages: I would argue that it's far from preferable, because you would have multiple things on different release schedules in one package.

Re: F29 System Wide Change: Discontinue PPC64 as Alternative Architecture

> "JK" == Jan Kurik writes: JK> https://fedoraproject.org/wiki/Changes/DiscontinuePPC64 This may be necessary, but it's sadly unfortunate as (so far as I can tell) it leaves us with only one big-endian architecture (s390x). And while it was not difficult to get a login on a ppc64 machine

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

> "CW" == Colin Walters writes: CW> I'd say it makes sense to revisit the default here globally in CW> Anaconda. Maybe. Have the issues which made XFS less suitable for use on laptops been resolved? The primary one I recall was that each mounted filesystem would have a

Re: Heads Up - openssl makefile and scripts for creating self signed certificates

> "TM" == Tomas Mraz writes: TM> Although it is much easier now to set up proper certificates for TM> your servers with Let's Encrypt, it is still not fully automatable TM> process (it needs at least some set up at the beginning for the TM> first issued certificate). Thus

Re: /bin/sh and lua; was: Re: common location of spec files in upstream sources

> "RPH" == R P Herrold writes: RPH> I noticed in the Scripts languages section the ** absence ** of RPH> /bin/sh (and not 'bash' with its 'bashisms'), and lua There's no "Scripts languages" section in the packaging guidelines as far as I'm aware. Are you referring to

Re: /bin/sh and lua; was: Re: common location of spec files in upstream sources

> "FW" == Florian Weimer writes: FW> It's often necessary to use Lua for scriptlets which run reliably FW> because RPM lacks delayed script execution. I guess it depends on how delayed you want them. The ordering is certainly well defined but it's all a bit esoteric.

Re: /bin/sh and lua; was: Re: common location of spec files in upstream sources

> "AW" == Adam Williamson writes: AW> FWIW, ISTR being told at some point that it's a good idea to write AW> scriptlets in lua because RPM should *always* be able to run lua AW> scriptlets, whereas at least in theory a scriptlet written in shell AW> script could

Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache

> "IG" == Igor Gnatenko writes: IG> First thing you should do is to open a ticket for FPC[0] in order to IG> fix guidelines. I'm still catching up on list mail but someone sent me a personal email about this. Not sure why they didn't open a ticket, but in

Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache

> "IG" == Igor Gnatenko writes: IG> Before FPC approves that it's really not needed, strictly speaking IG> is violation of packaging guidelines... I hope we're not so bureaucracy minded that we can't ignore obviously wrong things because they're on a wiki

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

> "JF" == John Florian writes: JF> One last thought, how friendly is this going to be with tools like JF> puppet and ansible? Well it has to be friendlier than authconfig, because generally authconfig isn't and can't be made idempotent. It will randomly reorder things

Re: How_do_I_request_commit_access_to_a_dist-git_repo where I'm admin ?

> "SB" == Sérgio Basto writes: SB> I don't have permissions on epel7 There are a few repos where the gitolite permission setup wasn't regenerated after the switch to pagure. I just checked and that definitely appears to be one of them, but I don't have permission to fix

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

> "JK" == Jan Kurik writes: JK> Python 2, when called as python or /usr/bin/python at RPM build time JK> (as identified by the RPM_BUILD_ROOT environment variable), will JK> print a deprecation warning to stderr. (Any program invoked during JK> build that invokes

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

> "MH" == Miro Hrončok writes: MH> This sounds good to me. It didn't occur to me that we can actually MH> set a dedicated env vars for our builds (which is even better). Well, doing so requires that we change an rpm macro to export this new env var in the same place

python2 dummy packages for EPEL

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) I'll

Re: python2 dummy packages for EPEL

It would of course be better if I actually provided links to the updates: python2-setuptools (EPEL6): https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-92c3e1b0e4 python2-sphinx (EPEL7): https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9cd64dfc3c python2-pytest (EPEL7):

Package Wishlist (Was: Working on a Dracut bug?)

(Trimmed CC list) > "i" == inderaue23 writes: i> btw. do you know where i could request new packages for fedora i> installations? You are welcome to add things to https://fedoraproject.org/wiki/Package_maintainers_wishlist However, Fedora generally works on the

[EPEL-devel] (no subject)

(This is mostly a duplicate of a post I sent to devel@. I wanted to alert epel-devel@ but didn't want to crosspost.) Following my proposal in https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages which met with favor from a number of folks here, I went ahead and set up four dummy

Re: [HEADS UP] Removal of systemd-units

> "IG" == Igor Gnatenko writes: IG> It's just 198 packages and we are just going to fix them for you in IG> following days. When posting big lists of packages, please consider running that list through

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

> "TD" == Troy Dawson writes: TD> If you have something like that, please change it to something like TD> this. TD> if 0%{?fedora} || 0%{?rhel} > 7 TD>%define with_python3 1 TD> %endif If things work as they have in the past, packages will need to explicitly be

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

> "FW" == Florian Weimer writes: FW> It could also be branched into Red Hat Enterprise Linux proper, and FW> in that case, it would be nice to minimize the differences. That would be kind of outside the scope of Fedora, though. Many of us watching from outside would

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

> "JB" == Josh Boyer writes: JB> Hm. On the one hand, that's a fair assumption to make. On the JB> other hand, it seems unnecessarily adversarial. I certainly didn't intend it that way; hell, none of that even entered my mind. To flip it around, to be

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. We have more things coming in concert with various distro changes that are happening, but I wanted to get these two out there now. - The icon cache scriptlets were removed from the scriptlet guidelines, as no live Fedora release needs

Re: Packaging wiki: shortcoming in Github Source0 (?)

> "PM" == Panu Matilainen writes: PM> Yes spectool was recommended by somebody else already, but PM> ultimately only rpm itself can truly parse a spec, spectool is just PM> a rough approximation (but usually does work in the more common PM> cases, yes) Actually the

Re: The New Hotness builds failing with py2_dist macros

Actually comprehending your message, I see it's not you building this package at all and it's not doing it in koji, either. So I wonder what environment is present when hotness is trying to build the SRPM. If somehow it doesn't have redhat-rpm-config installed (or epel-rpm-macros if running on

Re: The New Hotness builds failing with py2_dist macros

> "MC" == Michael Cullen writes: MC> returned 1: error: line 27: Dependency tokens must begin with MC> alpha-numeric, '_' or '/': BuildRequires:%{py2_dist nose} This implies that the %py2_dist macro isn't defined at that point in time and so you just get a

Heads up: automatic shebang munging in rawhide

With redhat-rpm-config-91-1.fc28 which is currently in rawhide comes automatic munging of the "#!" (shebang) line in executable scripts, as well as several additional checks. The following changes will be applied the shebang line of executables: 1) "#!/usr/bin/env foo" will be replaced with

Python2 stub packages now in EPEL stable

[For those who don't read epel-devel, this is a duplicate of a message also posted there.] The initial set of stub python2-* packages I created have now made their way to EPEL6 and EPEL7 stable, so packages can now depend on python2-setuptools, python2-six, python2-pytest and python2-sphinx in

[Guidelines change] Changes to the packaging guidelines

Just this one change, but it has implications for many packages. The Scriptlet guidelines have received several changes regarding the installation of shared libraries and ldconfig. Use of the new macros is detailed, and there is a new section on the scriptlets required when linker configuration

Re: Removal of BuildRoot

> "NG" == Neal Gompa writes: NG> What do you want it to be? What the other distros use seems far better to me. Alternately, just "rpmlintrc". - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send

Re: Removal of BuildRoot

> "NG" == Neal Gompa writes: NG> The problem with Bodhi is that it's too late. I don't disagree, but you've switched up your argument. You made the statement that Fedora doesn't care about rpmlint so there's no point in improving it. People do care, and rpmlint is

Re: Re: Dynamically-generated C stored in SVN is breaking our distribution because life is awful (was Re: F28 System Wide Change: GCC8)

> "NM" == Nicolas Mailhot writes: NM> BTW dovecot is broken by all the compiler and crypto changes, both NM> for the two last rebuilds (that failed) and the build before (that NM> succeeded but has broken auth which is sort of needed for an imap NM> server)

Help needed with new segfaults in frame unwinding under gcc8

I could really use some help from the gcc experts. A package I maintain, cyrus-imapd, contains two extensive test suites which we run at package build time. After the big flag day where we updated gcc and glibc and such in rawhide, one of the test suites now shows failures and produces 22 core

Re: Help needed with new segfaults in frame unwinding under gcc8

ogus values not just in one JJ> field, but in all of them. JJ> Jakub JJ> ___ devel mailing list JJ> -- devel@lists.fedoraproject.org To unsubscribe send an email to JJ> devel-le...@lists.fedoraproject.org -- Jason L Tibbitts III - ti...@math.uh.ed

Re: Help needed with new segfaults in frame unwinding under gcc8

I'm sorry, for the first time in decades I actually hit the send key sequence (Ctrl-C Ctrl-C) accidentally. > "JJ" == Jakub Jelinek writes: JJ> Strangely, --enable-network to mock was really needed so that the JJ> first testsuite passes. That's absolutely bizarre. JJ> I

Re: Help needed with new segfaults in frame unwinding under gcc8

Some more information: I looked through the Koschei logs for this package and it seemed it actually started failing before gcc8 went in. Specifically, the first failed build was on January 22, and the changes for that run were: mariadb-devel 3:10.2.12-2.fc28 -> 3:10.2.12-3.fc28

Re: Help needed with new segfaults in frame unwinding under gcc8

I'm sorry, for the first time in decades I actually hit the send key sequence (Ctrl-C Ctrl-C) accidentally. > "JJ" == Jakub Jelinek writes: JJ> Strangely, --enable-network to mock was really needed so that the JJ> first testsuite passes. That's absolutely bizarre. JJ> I

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

> "RR" == Roberto Ragusa writes: RR> When I proposed this kind of optimization in some mailing list RR> (maybe this one?!), I was answered that my method was not entirely RR> safe because there could have been problems for some rpm scripts RR> calling libraries that

Re: Removal of BuildRoot

> "NK" == Nico Kadel-Garcia writes: NK> While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete. epel-rpm-macros set up the default buildroot value for EPEL5 and thus rendered the BuildRoot: tag unnecessary well before that release went EOL. But even without that

Re: Removal of BuildRoot

> "DS" == David Sommerseth writes: DS> False positives are also easily filtered out by adding .rpmlint to DS> the dist-git repository. Which is an absolutely terrible name for that. Really. Why would anyone at all ever think it is a good idea to _hide_ the file that

Re: Removal of BuildRoot

> "NG" == Neal Gompa writes: NG> As upstream for rpmlint, I do not believe anyone cares at all about NG> rpmlint in Fedora. We seemingly care so little for it that the rpmlint status appears on every bodhi update. I did spend some time trying to make rpmlint better ages

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

> "CW" == Colin Walters writes: CW> Meanwhile, there are probably hundreds of people on this -devel list CW> who are capable of debugging and fixing things - some very CW> experienced engineers, yet some of them are here busily debating CW> minor things about spec files.

Re: RFC: BugURL in packages

> "KF" == Kevin Fenzi writes: KF> Does anyone have cycles to look into the best place to make this KF> change and how to get the override working on a per package basis? It appears that koji already forces several RPM tags: ; The vendor to use in rpm headers vendor=Fedora

Re: RFC: BugURL in packages

Or you can just add this: config_opts['macros']['%bugurl'] = 'http://bugz.fedoraproject.org/%name' to the mock site-defaults.cfg on the builders. For some reason I thought that we couldn't depend on %name to be stable in the case of subpackages but it appears to not matter. - J<

Re: RFC: BugURL in packages

So basically, koji has a list of macros (hardcoded in koji/__init__.py) which unfortunately carries the comment: #XXX - this needs to be configurable Those get turned into config_opts['macros']['%_foo']['whatever'] directives in the generated mock config. Some of those macros (%vendor,

Re: Help needed with new segfaults in frame unwinding under gcc8

> "JR" == John Reiser writes: JR> Please create a bugzilla report, or other well-known tracking JR> instance. But where? I don't even know whose problem this is. It's taken me days of what little free time I have just to figure out how to get the backtrace I was able

Re: Help needed with new segfaults in frame unwinding under gcc8

> "JR" == John Reiser writes: JR> Those one-line tracebacks, with no source file and no line number, JR> are a clue that valgrind could find no corresponding degbuginfo. JR> Please install the debuginfo for libcyrus_imap.so.0.0.0 and JR> libstdc++.so.6.0.25, then re-run

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

> "SJS" == Stephen John Smoogen writes: SJS> OK this is a problem on my part. I have taken sections which have SJS> MUST/WILL/SHOULD in them to be done and I have taken ones without SJS> that as general guidance. Unfortunately the guidelines simply do not consistently

Re: Help needed with new segfaults in frame unwinding under gcc8

> "JJ" == Jakub Jelinek writes: JJ> Can I get detailed info on how to reproduce this (most importantly, JJ> which src.rpm you are trying to build)? Sorry, that was all in the original message. The package is cyrus-imapd; all you have to do is check it out and do fedpkg

Re: Help needed with new segfaults in frame unwinding under gcc8

> "JJ" == Jakub Jelinek writes: JJ> Haven't managed to reproduce it, while there are some testsuite JJ> failures, they are due to timeouts and e.g. dmesg doesn't show any JJ> segvs nor traps. Of course I can reproduce this easily and it also happens in the buildsystem.

Re: Help needed with new segfaults in frame unwinding under gcc8

> "JJ" == Jakub Jelinek writes: JJ> Well, I'm seeing [...] So that's the first of the two test suites, which I've seen fail before but I haven't invested any time into debugging it. It's completely unrelated to any of the failures I'm talking about. You can just remove

Re: F29 System Wide Change: Remove GCC from BuildRoot

> "DPB" == Daniel P Berrangé writes: DPB> I'm suggesting committing actual changes. Creating several 1000 DPB> pull requests is just as much a burden on maintainers as expecting DPB> them to edit several 1000 specs themselves. I welcome automatic changes to the

Re: Removal of BuildRoot

> "LT" == Luya Tshimbalanga writes: LT> When you get a chance, would you also update the spec guideline as LT> well? Which spec guideline did you mean? If you were referring to the packaging guidelines, they have said that BuildRoot: should not be used since 2016:

Re: Help needed with new segfaults in frame unwinding under gcc8

> "JJ" == Jakub Jelinek writes: JJ> Ok, so the problem is ignoring important warnings, in this case: JJ> imap/xapian_wrap.cpp: In function 'int JJ> stem_version_set(Xapian::WritableDatabase*, int)': JJ> imap/xapian_wrap.cpp:267:1: warning: no return statement in function

Re: [Fedora-packaging] DRAFT: Change to Systemd Packaging Guidelines - Was Re: Services that shouldn't be started in the first place

> "GBC" == Gerald B Cox writes: To me this doesn't make much sense in the context in which you have put it. The existing hardware activation section is just this paragraph: - Hardware activation occurs when a service is installed but only turns on if a certain type of hardware is

Re: [Fedora-packaging] Re: DRAFT: Change to Systemd Packaging Guidelines - Was Re: Services that shouldn't be started in the first place

And I apologize, but I edited out, well, all of Gerald's message in my reply. I didn't quite intend to trim _all_ of the context there. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Guideline change: glibc malloc as the C/C++/Rust allocator

> "FW" == Florian Weimer writes: FW> I would like to request a change of the Packaging Guidelines, FW> advising packagers not to interpose malloc. How strong of a restriction are you looking for? This sort of feels like something which would at the strongest be a "SHOULD NOT" but maybe

Re: Got NVMe hardware? I need you!

I will happily send info for several devices here which have NVMe, but my regular use desktop has three NVMe devices. I sent info for /dev/nvme0 but would you prefer that I append something to my machine ID so that I can send the others? Simplified NVMe firmware updates would be great; I have

Re: Automating Package Review

> "RWMJ" == Richard W M Jones writes: RWMJ> I think we'd want to consider the security implications of RWMJ> accepting packages after only automated review. New packagers would need to be sponsored and so a human would still have to be involved at some point. (At least I certainly hope

Re: Orphaned Packages in rawhide (2018-08-27)

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> Unfortunately there is no "button" in pagure, and the process to ZJ> take a package is a manual releng ticket. If you're an admin then you can click the "Give the XXX project" button at the bottom. That will change the "main admin", and I'm

Re: Orphaned Packages in rawhide (2018-08-27)

So audiofile has eight current maintainers (plus all of gnome-sig) but somehow none of those maintainers has admin privileges on the repository. Would any of the maintainers like be made an admin so that SDL and everything that depends on it can drop out of this report? Just let me know and I'll

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> Can we patch rpm not to show this useless line? In the context of what I wrote, there's no "useless line". I assume you're talking about rpm -qi output, but I was being more general than that. Certainly we wouldn't patch out the GROUP

Re: Fedora 29 Mass Rebuild

> "AL" == Avram Lubkin writes: AL> Makes sense, but is this documented anywhere? It's in the EPEL FAQ: https://fedoraproject.org/wiki/EPEL/FAQ#Is_it_possible_to_get_a_package_only_into_EPEL_and_not_Fedora.3F - J< ___ devel mailing list --

Intent to retire denyhosts

Denyhosts is a daemon which watches for failed ssh login attempts and blocks them. I have long maintained denyhosts in Fedora and while I did not originally agree with it being branched to EPEL, I have done light maintenance on EPEL7 as well. The EPEL6 branch is, however, very old. The upstream

Re: Intent to retire denyhosts

> "CA" == Chris Adams writes: CA> Just as an FYI: I'm not sure fail2ban supports that out of the box, CA> but it is easy enough to: True, but denyhosts has the concept of a central synchronization server which can be shared by all installations globally. The original incarnation (by the

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - The packaging guidelines for enabling services by default were significantly revised to emphasize that services starting by default should fail only in exceptional conditions, and to provide additional guidance for services related

Re: Fedora 29 Mass Rebuild

> "AL" == Avram Lubkin writes: AL> We had issues, Bug 1600418, because python3-dns, which is intended AL> only for EPEL7, was included in the mass rebuild for 28 and had an AL> f28 branch created. Now it's been included in the f29 mass AL> rebuild. How do we keep this from happening? Well,

Re: Brainstorming about kernel updates with low disk space

> "CM" == Chris Murphy writes: CM> A few releases ago, Anaconda now defaults to a 1GiB boot partition CM> which should prevent the problem you're describing for anyone using CM> the default 3 retained kernels, as well as the extra kdump initramfs CM> if you're using kdump (not enabled by

Brainstorming about kernel updates with low disk space

I'd like to brainstorm a bit about how to make kernel updates more resilient to running out of disk space. I've talked to a few people on IRC about this but I'm not at the point where I know enough to file good bugs and figured that a larger discussion might help. Summary of my questions: Why

Re: Brainstorming about kernel updates with low disk space

> "CM" == Chris Murphy writes: CM> Why is /var/tmp running out of space? Is that really important? In this case it was due to things simply being too small (they are minimal VMs, after all) and dnf caching packages there. The fact that dnf downloads a significant but quite variable amount

Re: Brainstorming about kernel updates with low disk space

> "CM" == Chris Murphy writes: CM> But also the first new-kernel-pkg with --install calls grubby with CM> makedefault, which is what I think is setting grubenv with the new CM> kernel variable before the initramfs and final grub.cfg modification CM> are done. Right, which is why I wonder if

Re: Brainstorming about kernel updates with low disk space

> "CM" == Chris Murphy writes: CM> As I think about it, new-kernel-pkg is part of grubby. Yes, I assume it will go away and we'll be left with only the install-kernel infrastructure. Which would strip at least three layers from this onion. It also conveniently forces the issue, since it's

Re: Brainstorming about kernel updates with low disk space

> "CM" == Chris Murphy writes: CM> Well, I can't really parse this very well, but the default kernel CM> looks like it is changed by grubby, but I can't figure out the CM> ordering. It's seems plausible, perhaps likely, that it starts off CM> dracut and the grub2-editenv at the same time,

Re: Heads Up: python2 is marked as deprecated

> "RG" == Raphael Groner writes: RG> Does this deprecation of python2 mean requests for package review RG> with python2 only are now invalid? Well they certainly shouldn't be approved; the idea of deprecating packages in this manner is to prevent the set of things which depend on them from

Re: Packages which needlessly use %defattr

> "KF" == Kevin Fenzi writes: KF> I agree. If this could be done before mass rebuild we can catch any KF> issues/typos/mistakes in this with the mass rebuild. I've been away from computers for a bit, but I could certainly do this without too much effort. I just know that some people are

Re: Packages which needlessly use %defattr

> "NK" == Nico Kadel-Garcia writes: NK> Would you please post, or post a link to, your updated filter NK> script? It remains at https://pagure.io/fedora-misc-package-utilities : https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-needless-defattr I currently have no unpushed

Re: Packages which needlessly use %defattr

In case it wasn't obvious from all of the commit messages, I did go ahead and remove many needless %defattr directives from a large number of packages a few hours ago. I used the output of the find-needless-defattr script from https://pagure.io/fedora-misc-package-utilities as a guide for which

<    1   2   3   4   5   6   7   >