Re: Users with commit rights in src.fp.o but no more in packager group
On Wed, Aug 24, 2022 at 09:50:59PM +0200, Fabio Valentini wrote: > I think some of those *-team / *-sig / *-maint pseudo-group users are > outdated. Most of them probably pre-date the existence of actual > groups, so they are probably all ancient. For example, we removed the > xgl-maint pseudo-group a while ago, because it was actually unused, > and its associated bugzilla account was disabled. > I wonder for how many of these groups the same is true, and whether we > should actually remove them from all packages where that's the case. lvm-team is still in use as a package owner and default bugzilla assignee. To do anything of any significance using the account, we were instructed to open a ticket to ask for the change to be made for us. It has never been a member of the packager group because it was decided that accounts that are not individuals cannot sign the legal agreement that is a pre-requisite to being able to join that group. Alasdair ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Spam/scam links in bugzilla
On Thu, Nov 01, 2018 at 12:35:17PM +, Caolán McNamara wrote: > hfjkd1...@gmail.com is another one in RH bugzilla, the same scammers > are doing the same to the libreoffice bugzilla too I've cleaned those up and closed the accounts concerned (together with some other similar ones I found). They are defeating our existing anti-spam protection! If anyone spots any more, please open a ticket by emailing bugzilla-requests @redhat.com and one of us will clean it up. Alasdair ___ 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: LVM thinp expectations in anaconda 20
On Mon, Sep 30, 2013 at 10:04:08AM -0600, Chris Murphy wrote: For an LV to take advantage of thinp snapshots needs to be a virtual size LV drawn from the thin pool, correct? So it is a virtual size LV in any case, it's just that the installer isn't going to let users specify total LV virtual sizes greater than the pool, right? Yes, that's my undestanding. Alasdair -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LVM thinp expectations in anaconda 20
On Fri, Sep 27, 2013 at 11:55:43AM -0600, Chris Murphy wrote: I still can't choose a Desired Capacity that's larger than free space in the VG. Ergo, I can't create a virtual size LV. Is this expected? At this stage, yes. It might change in future, but I think it was felt to be both too much code to change and too much change for users to take on board if it was all changed at once. Alasdair -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What's this /run directory doing on my system and where does it come from?
On Wed, Mar 30, 2011 at 08:36:38AM -0400, Matthew Miller wrote: No flames from me. This is a sensible, thought-through change with cross-distro buy-in and no major downsides. It is outside of the FHS, but is in the _spirit_ of it, and would fit into an updated release of the standard, if there ever were one. Ack. A sensible and long-overdue attempt to address one of the short-comings of the standard. If the FHS isn't updated to reflect this, then it's only making itself less relevant. (lvm2 now gains a proper new location for /etc/lvm/cache.) Alasdair -- 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, Mar 30, 2011 at 03:05:35PM +0200, Ralf Corsepius wrote: On 03/30/2011 02:36 PM, Matthew Miller wrote: It is outside of the FHS, It's a clear violation of the FHS. Indeed, but there really is no suitable FHS-compliant location for files of these types, so we had no choice but to violate the standard up to now: nothing has changed in this respect. As I see things, the proposal is just to violate it in a much cleaner, co-ordinated and standardised way. Alasdair -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 10:15:20AM +, Richard W.M. Jones wrote: On Sun, Nov 14, 2010 at 01:14:18AM +0100, Lennart Poettering wrote: LVM actually slows down boot considerably. Not primarily because its code was slow or anything, but simply because it isn't really written in the way that things are expected to work these days. Almost - the delays are not any fundamental part of LVM2 itself, but come about from the simplistic way it is called by scripts during startup. Wait a long time for things to settle, then see what storage we can assemble and hope we can see all the bits we need. If instead you defined rules about what to activate and when, you could switch to an event-driven mechanism hooked into udev: When you see the whole of the Volume Group called rootvg, activate it. I once had a discussion about how we would incorporate this into upstart, but it was never a priority and I don't think anything happened about it. The LVM assembly at boot is expected to be run at a time where all disks have been found by the kernel and identified. (Again, that's just a constraint imposed by the current scripts, not anything fundamental to LVM.) The right way how to implement a logic like this is to wait exactly until all disks actually *needed* have shown up and at that time assemble LVM. Absolutely! (On a VG-by-VG basis.) Currently, to make LVM work, we however try to wait until *everything* thinkable is enumerated, not only the disks that are actually needed. A convenience - it makes the scripts simpler - but not a necessity. (And lvm2 can be - and is being slowly - improved to make it easier for such scripts.) I'd really like to hear from an LVM expert or two about this, because I can't believe that it's impossible to make this work better for the common single-disk-is-boot-disk single-PV case. The LVM metadata (which I've written code to read and decode in the past) contains the information needed. It's just about differing priorities not helped by responsibilities being split between developers of different packages. An example of the way I see it working is like this: Say you have a Volume Group VG1 across two PVs, PV1 and PV2, containing Logical Volume LV1 containing the root filesystem. You have a trigger rule saying When you see the whole of VG1, activate LV1 inside it and another saying When you see the filesystem with UUID X, mount it. (Default rules can be generic of course, like 'activate any VG when you see it' and 'activate any LV when you see it' and 'mount any filesystem when you see it'.) Device containing PV1 appears on system. Kernel sends uevent. udev rules ask each storage subsystem in turn Is this yours? - lvm2 subsystem spots the PV signature and claims ownership of it. It caches the LVM metadata from it. - Rule check performed but no rules match. Device containing PV2 appears on system. Kernel sends uevent. udev rules ask each storage subsystem in turn Is this yours? - lvm2 subsystem spots the PV signature and claims ownership of it. It caches the LVM metadata from it. - The rule to activate LV1 when the whole of VG1 is seen is triggered. LV1 is activated. Kernel sends uevent for arrival of the new VG1-LV1 block device on the system. udev rules ask each storage subsystem in turn Is this yours? - lvm2 subsystem finds no signature and answers No. - filesystem subsystem spots the filesystem signature and claims ownership. - The rule to mount the (root) filesystem is triggered. In summary: Each block device on the system has (at most) one owning subsystem recorded in a single database. (perhaps based around libblkid) Storage subsystems may support actions like scan and activate. Udev rules trigger scan. The exact nature of the abstractions used by the triggers would need further exploration. (Storage-subsystem-specific handling - central 'blob' cache, general triggers vs. private caches, private triggers.) Alasdair -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
