Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On 07/29/2013 08:38 PM, Ric Wheeler wrote: If application A does a stat or statvfs() call, sees 1GB of space left and then does a write, we could easily lose that race to any other application. If you want to reserve space, you need to grab the space yourself (always works with a large "write()" but preallocation can also help without dm-thin). In order to have it work "always", you'll have to write unpredictable data. If you write just zeros, the reservation isn't guaranteed if the file system supports compression. I'm pretty sure we want a crass layering violation for this one (probably a new mode flag for fallocate), to ensure proper storage reservation for things like VM images. -- Florian Weimer / Red Hat Product Security Team -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
Dne 31.7.2013 10:39, Florian Weimer napsal(a): On 07/29/2013 08:38 PM, Ric Wheeler wrote: If application A does a stat or statvfs() call, sees 1GB of space left and then does a write, we could easily lose that race to any other application. If you want to reserve space, you need to grab the space yourself (always works with a large "write()" but preallocation can also help without dm-thin). In order to have it work "always", you'll have to write unpredictable data. If you write just zeros, the reservation isn't guaranteed if the file system supports compression. I'm pretty sure we want a crass layering violation for this one (probably a new mode flag for fallocate), to ensure proper storage reservation for things like VM images. If someone wants to use preallocation - thus always allocate whole space, than there is no reason to use provisioned devices unless someone want's to use its snapshot feature (for this there could be probably introduced something like creation of fully provisioned device) - but then you end-up with the same problem once you start to use snapshot. For me this rather looks like misuse of thin provisioning. ThinP should be configured in a way that admin is able to extend pool to honour promised space if really needed. It's not a good idea, to provision 1EB if you have at most just 1TB disk and then you expect you will have no problems when someone fallocate() 500TB. I.e. if someone is using iSCSI disc array with 'hw' thin provisioning support, there is no scsi command to provision space - it's admin's work to ensure there is enough disc space to keep up with user demands Maybe - just an idea - there could be a kernel bit-flag somewhere, which might tell if the device used by fs is 'fully provisioned' or 'thin provisioned' (something like rotational/non-rotational) But there is no way to return information about free disc space - since it's highly subjective value and moreover very expensive to calculate. Zdenek -- 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: Obsoleting ConsoleKit once and for all
On Tue, Jul 30, 2013 at 11:59 PM, Lennart Poettering wrote: > BOn Tue, 30.07.13 16:14, Dan Williams (d...@redhat.com) wrote: > > > On Tue, 2013-07-30 at 23:03 +0200, Lars Seipel wrote: > > > On Tue, Jul 30, 2013 at 04:28:55PM +0200, Christoph Wickert wrote: > > > > thunar and pcmanfm are file managers and require ConsoleKit for > handling > > > > removable storage. > > > > > > Are you sure you aren't confusing this with something? HAL maybe? > > > > There's some interaction with ConsoleKit to ensure that the removable > >1;3406;0c storage is tied to a specific session so that the logged-in > user can > > actually modify their USB drive. Otherwise it's only accessible to > > 'root'. > > > > So yes, something *else* (HAL, udisks, etc) actually handles the > > mounting, but there's some other components involved in permissions and > > mount location, and that's where ConsoleKit helps out. > > But that's stuff that is hidden beneath udev/udisks not sure why a file > manager needs to know that... > There is some stuff regarding thunar on this blog post by one of the thunar developers: http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors Johannes > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Failures of noarch package builds on ARM (Re: ARM Status)
On Sun, Jul 28, 2013 at 03:05:34PM -0500, Dennis Gilmore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > hi all, > > I have imported ARM into primary and enabled armv7hl in the arches to > be built. right now the KDE stack is not entirely built and brought in > due to https://bugzilla.redhat.com/show_bug.cgi?id=988114 as soon as it > is resolved we will get everything fixed and brought in. at that point > arm will be added to the nightly composes. I've just attempted to build mingw-libvirt (which is noarch) in rawhide and was (unlucky?) that it got scheduled on an ARM builder. The build failed with checking build system type... Invalid configuration `armhfp-redhat-linux-gnu': machine `armhfp-redhat' not recognized http://koji.fedoraproject.org/koji/taskinfo?taskID=568 This is odd because the mingw-libvirt src.rpm has the exact same tar.gz that we use in the native libvirt src.rpm which accepts arm as a build system type. So I'd expect that the configure script is already new enough to work with armv7 hosts at least. Looking to see if mingw-libvirt was ever tested on ARM secondary builders, I can't find any build logs. Querying the noarch.rpm packages hosted on the ARM secondary builder koji host at: http://arm.koji.fedoraproject.org/packages/mingw-libvirt/1.0.5/1.fc20/noarch/ shows that they were built on the Fedora primary koji instance. Randomly picking some other mingw packages (mingw-libpng and mingw-libxml2) shows they were also all build on x86 hosts and trying a build of them on arm hosts causes the same failure. So am I right in thinking any noarch RPMs were just copied across to the ARM koji as-is, without attempting to rebuild them ? If so, it seems we might have a bunch of noarch packages which are going to turn out to be broken if unlucky to have their builds scheduled on ARM. Side-note, even if the packages worked fine, is it a good idea to allow noarch builds to be scheduled on ARM, given that ARM is so much slower ? It seems we're wasting precious ARM builder cycles, as well as maintainer time, by letting noarch builds go to the slower ARM builders instead of x86 builder hosts. /me goes to play russian roulette triggering rebuilds of the mingw-libvirt package until koji picks an x86 host Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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: Failures of noarch package builds on ARM (Re: ARM Status)
On Wed, 31 Jul 2013 11:25:45 +0100 "Daniel P. Berrange" wrote: > On Sun, Jul 28, 2013 at 03:05:34PM -0500, Dennis Gilmore wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > hi all, > > > > I have imported ARM into primary and enabled armv7hl in the arches to > > be built. right now the KDE stack is not entirely built and brought in > > due to https://bugzilla.redhat.com/show_bug.cgi?id=988114 as soon as it > > is resolved we will get everything fixed and brought in. at that point > > arm will be added to the nightly composes. > > I've just attempted to build mingw-libvirt (which is noarch) in rawhide > and was (unlucky?) that it got scheduled on an ARM builder. The build > failed with > > checking build system type... Invalid configuration > `armhfp-redhat-linux-gnu': machine `armhfp-redhat' not recognized IIRC this is an issue of not translating the arm build architecture from armhfp to armv7hl by koji/mock/rpm Dan > http://koji.fedoraproject.org/koji/taskinfo?taskID=568 > > This is odd because the mingw-libvirt src.rpm has the exact same > tar.gz that we use in the native libvirt src.rpm which accepts > arm as a build system type. So I'd expect that the configure > script is already new enough to work with armv7 hosts at least. > > Looking to see if mingw-libvirt was ever tested on ARM secondary > builders, I can't find any build logs. Querying the noarch.rpm > packages hosted on the ARM secondary builder koji host at: > > http://arm.koji.fedoraproject.org/packages/mingw-libvirt/1.0.5/1.fc20/noarch/ > > shows that they were built on the Fedora primary koji instance. > > Randomly picking some other mingw packages (mingw-libpng and > mingw-libxml2) shows they were also all build on x86 hosts and > trying a build of them on arm hosts causes the same failure. > > So am I right in thinking any noarch RPMs were just copied across > to the ARM koji as-is, without attempting to rebuild them ? > > If so, it seems we might have a bunch of noarch packages which > are going to turn out to be broken if unlucky to have their > builds scheduled on ARM. > > Side-note, even if the packages worked fine, is it a good idea to > allow noarch builds to be scheduled on ARM, given that ARM is so > much slower ? It seems we're wasting precious ARM builder cycles, > as well as maintainer time, by letting noarch builds go to the > slower ARM builders instead of x86 builder hosts. > > /me goes to play russian roulette triggering rebuilds of the > mingw-libvirt package until koji picks an x86 host > > Regards, > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Dan Horák -- 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: Failures of noarch package builds on ARM (Re: ARM Status)
On Wed, Jul 31, 2013 at 01:03:33PM +0200, Dan Horák wrote: > On Wed, 31 Jul 2013 11:25:45 +0100 > "Daniel P. Berrange" wrote: > > > On Sun, Jul 28, 2013 at 03:05:34PM -0500, Dennis Gilmore wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > hi all, > > > > > > I have imported ARM into primary and enabled armv7hl in the arches to > > > be built. right now the KDE stack is not entirely built and brought in > > > due to https://bugzilla.redhat.com/show_bug.cgi?id=988114 as soon as it > > > is resolved we will get everything fixed and brought in. at that point > > > arm will be added to the nightly composes. > > > > I've just attempted to build mingw-libvirt (which is noarch) in rawhide > > and was (unlucky?) that it got scheduled on an ARM builder. The build > > failed with > > > > checking build system type... Invalid configuration > > `armhfp-redhat-linux-gnu': machine `armhfp-redhat' not recognized > > IIRC this is an issue of not translating the arm build architecture > from armhfp to armv7hl by koji/mock/rpm Looks like redhat-rpm-config is responsible for setting up arch mappings/translation, so I filed the following BZ against it https://bugzilla.redhat.com/show_bug.cgi?id=990519 Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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: F20 Self Contained Change: Ruby on Rails 4.0
- Original Message - > - Original Message - > > = Proposed Self Contained Change: Ruby on Rails 4.0 = > > https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0 > > > > Change owner(s): Vít Ondruch , Josef Stříbný > > , ruby-...@lists.fedoraproject.org > > > > Ruby on Rails 4.0 is the latest version of well know web framework written > > in > > Ruby. > > > > == Detailed description == > > The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace > > with > > it. Therefore the whole Ruby on Rails stack should be updated from 3.2 in > > Fedora 19 to 4.0 (latest version) in Fedora 20. This will ensure that all > > the > > Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby > > on > > Rails. > > > > == Scope == > > Proposal owners: > > * The whole Rails stack has to be updated > > * New additional gems will have to be packaged > > * Some dependencies of the Rails stack will need update > > > > For the list, see [1] > > > > Other developers: N/A (not a System Wide Change) > > Release engineering: N/A (not a System Wide Change) > > Policies and guidelines: N/A (not a System Wide Change) > > FESCo on yesterday's meeting asked to escalate this Change to > System Wide Change as they have concerns about the impact on > dependencies, namely OpenShift. > > Please, update your page and fill in the required sections for > System Wide Change with more detailed Scope. Change page has been updated to reflect concerns raised in this thread and by FESCo and is now in System Wide category. http://fedoraproject.org//wiki/Changes/Ruby_on_Rails_4.0 Jaroslav > Thanks > Jaroslav > -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Mon, Jul 29 2013 at 2:49pm -0400, Daniel P. Berrange wrote: > On Mon, Jul 29, 2013 at 02:38:23PM -0400, Ric Wheeler wrote: > > On 07/29/2013 10:18 AM, Daniel P. Berrange wrote: > > >On Mon, Jul 29, 2013 at 08:01:23AM -0600, Chris Murphy wrote: > > >>On Jul 29, 2013, at 6:30 AM, "Daniel P. Berrange" > >>redhat.com> wrote: > > >> > > >>>Yep, we need to be able to report free space on filesystems, so that > > >>>apps provisioning virtual machines can get an idea of how much storage > > >>>they can provide to VMs without risk of over comitting. > > >>> > > >>>I agree that we really want the kernel, or at least a reusable shared > > >>>library, to provide some kind of interface to determine this, rather > > >>>than requiring every userspace app which cares to re-invent the wheel. > > >>What does it mean for an app to use stat to get free space, and then > > >>proceeds to create too big a VM image in a directory that has a quota > > >>set? I still think apps are asking an inappropriate/unqualified question > > >>by asking for volume free space, instead of what's available to them for > > >>a specified path. > > > From an API POV, libvirt doesn't need/care about the free space on the > > >volume underlying the filesystem. We actually only care about the free > > >space in a given directory that we're using for disk images. It just > > >happens that we implement this using statvfs() currently. So when I > > >ask for an API above, don't take this to mean I want a statvfs() that > > >knows about sparse volumes. An API or syscall that provides free space > > >for individual directories is fine with me. > > > > > > > Just another note, it is never safe to assume that storage under any > > file system is yours for the taking. > > > > If application A does a stat or statvfs() call, sees 1GB of space > > left and then does a write, we could easily lose that race to any > > other application. > > This race doesn't matter from libvirt's POV. It is just providing a > mechanism via its API. It is upto the management application using > libvirt to make use of the mechanism to provide a usage policy. > Their usage scenario may well enable them to make certain assumptions > about the storage that you could not otherwise do in a race free > manner. > > In addition, even in more general purpose usage scenarios, it does > not neccessarily matter if there is a race, because there can be a > second line of defence. For example, KVM can be set to pause the VM > upon ENOSPC errors, giving management application or administrator > the chance to expand capacity the underlying storage and then unpause > the guest. In that case checking the free space is mostly just a > sanity check which serves to avoid hitting the pause-on-ENOSPC scenario > too frequently. Running out of free space _should_ be extremely rare. A properly configured dm-thin pool will have adequate free space, with an appropriate low water mark, that would give admins ample time to extend (even if a human were to do it). But lvm2 has support to autoextend the thin-pool with free space in the parent volume group. But I'm just talking about the not-really-chicken solution of leaning on a properly configured system (either by admins in a data center or by fedora developers with sane defaults). As an aside, this extra free space checking that KVM is doing is really broken by design (polling sucks -- especially if this polling is happening in the host for each guest). Would be much better to leverage something like lvm2 with a custom dmeventd plugin that fires when it receives the low watermark and/or -ENOSPC event. Thinly provisioned volumes offer the prospect of doing away with this polling -- as such proper dm-thin integration has been on the virt roadmap for a while. Just never seems to happen. Mike -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Mon, Jul 29 2013 at 2:48pm -0400, Eric Sandeen wrote: > On 7/27/13 11:56 AM, Lennart Poettering wrote: > > On Fri, 26.07.13 22:13, Miloslav Trmač (mitr at volny.cz) wrote: > > > >> Hello all, > >> with thin provisioning available, the total and free space values > >> reported by a filesystem do not necessarily mean that that much space > >> is _actually_ available (the actual backing storage may be smaller, or > >> shared with other filesystems). > >> > >> If your package reports disk space usage to users, and bases this on > >> filesystem free space, please consider whether it might need to take > >> LVM thin provisioning into account. > >> > >> The same applies if your package automatically allocates a certain > >> proportion of the total or available space. > >> > >> A quick way to check whether your package is likely to be affected, is > >> to look for statfs() or statvfs() calls in C, or the equivalent in > >> your higher-level library / programming language. > > > > Well, I am pretty sure the burden must be on the file systems to report > > a useful estimate free blocks value in statfs()/statvfs(). Exporting that > > problem to userspace and expecting userspace to work around this is just > > wrong. In fact, this would be quite an API breakage if applications > > cannot rely that the value returned is at least a rough estimate on how > > much data can be stored on disk. > > > > journald will scale how much disk usage it will use of /var/log/journal > > based on the file system size and free level. It will also module the > > per-service rate limit levels based on the amount of free disk space. If > > you break the API of statfs()/statvfs(), then you will end up break this > > and all programs like it. > > Any program needs to be prepared for ENOSPC; as Ric mentioned elsewhere, > until you successfully write to it, it's not yours! :) (Ok, thinp > running out of space won't generate ENOSPC today, either, but you see > my general point...) > > And how much space are we really talking about here? If you're running > thin-provisioning on thin margins, especially w/o some way to automatically > hot-add storage, you're probably doing it wrong. > > (And if journald sees "100T free" and decides it can use 50T of that, > it's doing it wrong, too) ;) > > The truth is somewhere in the middle, but quibbling over whether this > app or that can claim a bit of space behind a thin-provisioned volume > probably isn't useful. Right, so picking up on what we've discussed: adding the ability to have fallocate propagate to the underlying storage via a new REQ_RESERVE bio (if the storage opts-in, which dm-thinp could). This bio would be the reciprocal of discard -- thus enabling the caller to efficiently reserve space in the underlying storage (e.g. dm-thin-pool). So volumes or apps (e.g. journald) that _expect_ to have fully-provisioned space from thinp could. This would also allow for a hyrid setup where the thin-pool is configured to use a smaller block size to benefit taking many snapshots -- but then allows select apps and/or volumes to reserve contiguous space from the thin-pool. It obviously also offers the other traditional fallocate benefits too (reserving large contiguous space for performance, etc). I'll draft an RFC patch or 2 for LKML... may take some time for me to get to it but I can make it a higher priority if others have serious interest. > The admin definitely needs tools to see the state of thinly provisioned > storage, but that's the admin's job to worry about, not the app's, IMHO. Yeah, in a data center the admin really should be all over these thinp concerns, making them a non-issue. But on the desktop the fedora developers need to provide sane policy/defaults. Mike -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Wed, Jul 31 2013 at 5:52am -0400, Zdenek Kabelac wrote: > Dne 31.7.2013 10:39, Florian Weimer napsal(a): > >On 07/29/2013 08:38 PM, Ric Wheeler wrote: > > > >>If application A does a stat or statvfs() call, sees 1GB of space left > >>and then does a write, we could easily lose that race to any other > >>application. > >> > >>If you want to reserve space, you need to grab the space yourself > >>(always works with a large "write()" but preallocation can also help > >>without dm-thin). > > > >In order to have it work "always", you'll have to write unpredictable data. > >If you write just zeros, the reservation isn't guaranteed if the file system > >supports compression. > > > >I'm pretty sure we want a crass layering violation for this one (probably a > >new mode flag for fallocate), to ensure proper storage reservation for things > >like VM images. > > > If someone wants to use preallocation - thus always allocate whole space, > than there is no reason to use provisioned devices unless someone > want's to use its snapshot feature (for this there could be > probably introduced something like creation of fully provisioned > device) - but then you end-up > with the same problem once you start to use snapshot. > > For me this rather looks like misuse of thin provisioning. > > ThinP should be configured in a way that admin is able to extend > pool to honour promised space if really needed. It's not a good > idea, to provision 1EB if you have at most just 1TB disk and then > you expect you will have no problems when someone fallocate() 500TB. fallocate doesn't allow you to reserve more physical space than you have (or allowed via quota). > I.e. if someone is using iSCSI disc array with 'hw' thin > provisioning support, there is no scsi command to provision space - > it's admin's work to ensure there is enough disc space to keep up > with user demands > > Maybe - just an idea - there could be a kernel bit-flag somewhere, > which might tell if the device used by fs is 'fully provisioned' or > 'thin provisioned' (something like rotational/non-rotational) But > there is no way to return information about free disc space - since > it's highly subjective value and moreover very expensive to > calculate. If things like journald _need_ to have a sysfs flag that denotes the volume it is writing to is thinp then I'd like to understand what it'd do differently knowing that info. Would it conditionally call fallocate() -- assuming dm-thinp grows REQ_RESERVE support like I mentioned in my previous post. I see little value in exposing whether some portion of the storage stack is thin or not. What is an app to do with that info? It'd have to do things like: 1) determine the blockdevice the FS is layered on 2) lookup sysfs file for that device.. a filesystem can span multiple devices.. some time some not. It is just a rat's nest. Thinly provisioned storage this isn't exactly a new concept. But the Linux provided target obviously engages other parts of the OS to properly support it (at a minimum the volume manager and the installer). If the fallocate() triggered REQ_RESERVE passdown to the underlying storage provides a reasonable stop gap we can really explore it -- at least we'd be piggybacking on an established interface that returns success or failure. Mike -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On 07/31/2013 10:32 AM, Mike Snitzer wrote: On Mon, Jul 29 2013 at 2:48pm -0400, Eric Sandeen wrote: On 7/27/13 11:56 AM, Lennart Poettering wrote: On Fri, 26.07.13 22:13, Miloslav Trmač (mitr at volny.cz) wrote: Hello all, with thin provisioning available, the total and free space values reported by a filesystem do not necessarily mean that that much space is _actually_ available (the actual backing storage may be smaller, or shared with other filesystems). If your package reports disk space usage to users, and bases this on filesystem free space, please consider whether it might need to take LVM thin provisioning into account. The same applies if your package automatically allocates a certain proportion of the total or available space. A quick way to check whether your package is likely to be affected, is to look for statfs() or statvfs() calls in C, or the equivalent in your higher-level library / programming language. Well, I am pretty sure the burden must be on the file systems to report a useful estimate free blocks value in statfs()/statvfs(). Exporting that problem to userspace and expecting userspace to work around this is just wrong. In fact, this would be quite an API breakage if applications cannot rely that the value returned is at least a rough estimate on how much data can be stored on disk. journald will scale how much disk usage it will use of /var/log/journal based on the file system size and free level. It will also module the per-service rate limit levels based on the amount of free disk space. If you break the API of statfs()/statvfs(), then you will end up break this and all programs like it. Any program needs to be prepared for ENOSPC; as Ric mentioned elsewhere, until you successfully write to it, it's not yours! :) (Ok, thinp running out of space won't generate ENOSPC today, either, but you see my general point...) And how much space are we really talking about here? If you're running thin-provisioning on thin margins, especially w/o some way to automatically hot-add storage, you're probably doing it wrong. (And if journald sees "100T free" and decides it can use 50T of that, it's doing it wrong, too) ;) The truth is somewhere in the middle, but quibbling over whether this app or that can claim a bit of space behind a thin-provisioned volume probably isn't useful. Right, so picking up on what we've discussed: adding the ability to have fallocate propagate to the underlying storage via a new REQ_RESERVE bio (if the storage opts-in, which dm-thinp could). This bio would be the reciprocal of discard -- thus enabling the caller to efficiently reserve space in the underlying storage (e.g. dm-thin-pool). So volumes or apps (e.g. journald) that _expect_ to have fully-provisioned space from thinp could. I think that this would be really useful and, as you mention, is the mirror image of our discard support ric This would also allow for a hyrid setup where the thin-pool is configured to use a smaller block size to benefit taking many snapshots -- but then allows select apps and/or volumes to reserve contiguous space from the thin-pool. It obviously also offers the other traditional fallocate benefits too (reserving large contiguous space for performance, etc). I'll draft an RFC patch or 2 for LKML... may take some time for me to get to it but I can make it a higher priority if others have serious interest. The admin definitely needs tools to see the state of thinly provisioned storage, but that's the admin's job to worry about, not the app's, IMHO. Yeah, in a data center the admin really should be all over these thinp concerns, making them a non-issue. But on the desktop the fedora developers need to provide sane policy/defaults. Mike -- 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: Default libkrb5 ccache location
On Fri, Jul 26, 2013 at 07:40:39PM +0200, Lennart Poettering wrote: > On Fri, 26.07.13 11:01, Stephen Gallagher (sgall...@redhat.com) wrote: > > > > > I'm CCing Lennart and Kay on the discussion about this. Creating this > > symlink in the oddjob would be somewhat error-prone. I'd rather that > > we ask logind to carry a patch just for F19 where the creation of > > XDG_RUNTIME_DIR would include this symlink. > > Stephen, so Kay convinced me that it might be OK to handle su/sudo and > su -l/sudo -i differently from the rest and accept that we have sessions > that are started out of other sessions. Thanks, good work Kay! ;-) > pam_systemd would need a new argument force-new=1 or so, which is > passed for "su -l" and "sudo -i" but not otherwise. THis would be passed > along CreateSession() to logind. When specified this would result in a It would be nice to backport this feature to f19 too. Karel -- Karel Zak http://karelzak.blogspot.com -- 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: [virt-tools-list] AppIndicator3 not appindicator
On Tue, 2013-07-30 at 21:05 +0200, poma wrote: > OK, Adam can you please clarify this[1] lib*indicator* thingies on > Fedora, so we can safely do: > yum remove lib\*indicator\* The only reason I ever packaged it was as part of an abortive attempt to build Unity. I never built anything against it. I don't know why anything else might depend on it, but so far as I'm concerned it's useless. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)
Am 30.07.2013 11:35, schrieb Ian Malone: > This is the price you pay for having updated versions of libraries > with security fixes and functionality, and it's why Linux > distributions use open source (and one reason non OS software is > tricky), provided the library API hasn't changed you just rebuild > against the newer library. The original developer doesn't need to know > what version you're building against. Alternatively if there's a > vulnerability in an old zlib or libxml (not unheard of so far as I > know) there is a reason i mentoined libxml https://www.google.at/search?q=libxml2+CVE http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1969 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2877 signature.asc Description: OpenPGP digital signature -- 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: Rebuild of Boost dependees
2013/7/30 Jerry James : > On Mon, Jul 29, 2013 at 10:01 AM, Petr Machata wrote: >> >> polybori5663365 SCONS: internal error in regular >> expression engine > > > I will try to figure this one out. This should be 32 bit only. http://bugs.python.org/issue17998 It should be possible to workaround the problem in polybori's SConstruct, just that the trivial solution does not work, but I did not notice any problems after rebuilding python with the patch in the bugs.python.org report... > -- > Jerry James > http://www.jamezone.org/ > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Paulo -- 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: [virt-tools-list] AppIndicator3 not appindicator
On 30.07.2013 21:25, Adam Williamson wrote: > On Tue, 2013-07-30 at 21:05 +0200, poma wrote: > >> OK, Adam can you please clarify this[1] lib*indicator* thingies on >> Fedora, so we can safely do: >> yum remove lib\*indicator\* > > The only reason I ever packaged it was as part of an abortive attempt to > build Unity. I never built anything against it. I don't know why > anything else might depend on it, but so far as I'm concerned it's > useless. > OK Adam, no problemos, thanks for the replay. Cole, please omit my patch. Sorry for the noise and thanks for your patience. poma -- 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: Obsoleting ConsoleKit once and for all
On Wed, Jul 31, 2013 at 3:02 AM, Johannes Lips wrote: > On Tue, Jul 30, 2013 at 11:59 PM, Lennart Poettering > wrote: >> >> BOn Tue, 30.07.13 16:14, Dan Williams (d...@redhat.com) wrote: >> >> > On Tue, 2013-07-30 at 23:03 +0200, Lars Seipel wrote: >> > > On Tue, Jul 30, 2013 at 04:28:55PM +0200, Christoph Wickert wrote: >> > > > thunar and pcmanfm are file managers and require ConsoleKit for >> > > > handling >> > > > removable storage. >> > > >> > > Are you sure you aren't confusing this with something? HAL maybe? >> > >> > There's some interaction with ConsoleKit to ensure that the removable >> >1;3406;0c storage is tied to a specific session so that the logged-in >> > user can >> > actually modify their USB drive. Otherwise it's only accessible to >> > 'root'. >> > >> > So yes, something *else* (HAL, udisks, etc) actually handles the >> > mounting, but there's some other components involved in permissions and >> > mount location, and that's where ConsoleKit helps out. >> >> But that's stuff that is hidden beneath udev/udisks not sure why a file >> manager needs to know that... > > There is some stuff regarding thunar on this blog post by one of the thunar > developers: > http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors > Chris, Please file a bug with various upstreams (if you haven't already) to switch to udisks so we can retire ConsoleKit. MATE no longer has any use for it and neither should XFCE. I only picked up as a knee jerk reaction. It shouldn't be that hard for upstreams to move away from it. It wasn't for us. Dan -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Jul 31, 2013, at 8:32 AM, Mike Snitzer wrote: > But on the desktop the fedora > developers need to provide sane policy/defaults. Right. And the concern I have (other than a blatant bug), is the F20 feature for the installer to create thinp LVs; and to do that the installer needs to know what sane default parameters are. I think perhaps determining those defaults is non-obvious because of my experience in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=984236 If I'm going to use thinP mostly for snapshots, then that suggests a smaller chunk size at thin pool creation time; whereas if I have no need for snapshots but a greater need for provisioning then a larger chunk size is better. And asking usage context in the installer, I think is a problem. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 17 End of Life
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As of 30th July 2013, Fedora 17 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 17. A previous reminder was sent on July 3rd [0]. Fedora 18 will continue to receive updates until approximately one month after the release of Fedora 20. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [1]. The Fedora Project wiki also contains instructions [2] on how to upgrade from a previous release of Fedora to a version receiving updates. Cheers, Dennis [0] https://lists.fedoraproject.org/pipermail/announce/2013-July/003169.html [1] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule [2] http://fedoraproject.org/wiki/DistributionUpgrades -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlH5RDcACgkQkSxm47BaWfeGyQCfRaTPrFR2cZfg24tDmyEFL+j8 VIEAnRBsiNAYq+Pc6voWfC3DarHXH+qn =gA5+ -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora ARM Weekly Status Meeting 2013-07-31
Good day all, Please join us today (Wednesday, July 31th) at 4PM EDT (8PM UTC) for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode. On the agenda so far.. 0) Status of ACTION items from our previous meeting 1) Problem packages 2) Kernel Status Update 3) Aarch64 - Status Update, problem packages - Koji Update 4) Open Floor If there is something that you would like to discuss that isn't mentioned please feel free to bring it up at the end of the meeting or send an email to the list. -- 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: Schedule for Wednesday's FESCo Meeting (2013-07-31)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today's FESCo meeting is *CANCELED* due to lack of quorum. FESCo members are advised to vote in the FESCo Trac. On 07/30/2013 08:11 AM, Stephen Gallagher wrote: > Following is the list of topics that will be discussed in the > FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on > irc.freenode.net. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/UTCHowto > > or run: date -d '-MM-DD HH:MM UTC' > > > Links to all tickets below can be found at: > https://fedorahosted.org/fesco/report/9 > > = Followups = > > #topic #1132 libtool + %global _hardened_build 1 = no full > hardening .fesco 1132 https://fedorahosted.org/fesco/ticket/1132 > > #topic #1095 Fedora 20 schedule proposal .fesco 1095 > https://fedorahosted.org/fesco/ticket/1095 > > #topic #1140 F20 Self Contained Changes - week 2013-07-10 - > 2013-07-17 .fesco 1140 https://fedorahosted.org/fesco/ticket/1140 > > #topic #1143 F20 System Wide Change: No Default Sendmail - > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail .fesco > 1143 https://fedorahosted.org/fesco/ticket/1143 > > #topic #1144 F20 System Wide Change: No Default Syslog - > https://fedoraproject.org/wiki/Changes/NoDefaultSyslog .fesco 1144 > > > = New business = > > #topic #1139 ProvenPackager Request affix .fesco 1139 > https://fedorahosted.org/fesco/ticket/1139 > > #topic #1145 F20 System Wide Change: SSD cache - > https://fedoraproject.org/wiki/Changes/SSD_cache .fesco 1145 > https://fedorahosted.org/fesco/ticket/1145 > > #topic #1146 F20 System Wide Change: Visible Cloud - > https://fedoraproject.org/wiki/Changes/VisibleCloud .fesco 1146 > https://fedorahosted.org/fesco/ticket/1146 > > #topic #1147 F20 System Wide Change: Web Assets - > https://fedoraproject.org/wiki/Changes/Web_Assets .fesco 1147 > https://fedorahosted.org/fesco/ticket/1147 > > #topic #1148 F20 System Wide Change: Application Installer - > https://fedoraproject.org/wiki/Changes/AppInstaller .fesco 1148 > https://fedorahosted.org/fesco/ticket/1148 > > = Open Floor = > > For more complete details, please visit each individual ticket. > The report of the agenda items can be found at > https://fedorahosted.org/fesco/report/9 > > If you would like to add something to this agenda, you can reply > to this e-mail, file a new ticket at > https://fedorahosted.org/fesco, e-mail me directly, or bring it up > at the end of the meeting, during the open floor topic. Note that > added topics may be deferred until the following meeting. > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH5S9QACgkQeiVVYja6o6OhpwCfWaMs5PjVxDI4sGcje2CCyweY 2lYAn0ggtlPRq56a+SFABKdWLHwnKQes =HkpT -END PGP SIGNATURE- -- 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: Schedule for Wednesday's FESCo Meeting (2013-07-31)
- Original Message - > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Today's FESCo meeting is *CANCELED* due to lack of quorum. FESCo > members are advised to vote in the FESCo Trac. I'd like to ask to vote for the Schedule ticket specifically as the next FESCo meeting is after currently scheduled F20 Branch date. Thanks Jaroslav > > On 07/30/2013 08:11 AM, Stephen Gallagher wrote: > > Following is the list of topics that will be discussed in the > > FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on > > irc.freenode.net. > > > > To convert UTC to your local time, take a look at > > http://fedoraproject.org/wiki/UTCHowto > > > > or run: date -d '-MM-DD HH:MM UTC' > > > > > > Links to all tickets below can be found at: > > https://fedorahosted.org/fesco/report/9 > > > > = Followups = > > > > #topic #1132 libtool + %global _hardened_build 1 = no full > > hardening .fesco 1132 https://fedorahosted.org/fesco/ticket/1132 > > > > #topic #1095 Fedora 20 schedule proposal .fesco 1095 > > https://fedorahosted.org/fesco/ticket/1095 > > > > #topic #1140 F20 Self Contained Changes - week 2013-07-10 - > > 2013-07-17 .fesco 1140 https://fedorahosted.org/fesco/ticket/1140 > > > > #topic #1143 F20 System Wide Change: No Default Sendmail - > > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail .fesco > > 1143 https://fedorahosted.org/fesco/ticket/1143 > > > > #topic #1144 F20 System Wide Change: No Default Syslog - > > https://fedoraproject.org/wiki/Changes/NoDefaultSyslog .fesco 1144 > > > > > > = New business = > > > > #topic #1139 ProvenPackager Request affix .fesco 1139 > > https://fedorahosted.org/fesco/ticket/1139 > > > > #topic #1145 F20 System Wide Change: SSD cache - > > https://fedoraproject.org/wiki/Changes/SSD_cache .fesco 1145 > > https://fedorahosted.org/fesco/ticket/1145 > > > > #topic #1146 F20 System Wide Change: Visible Cloud - > > https://fedoraproject.org/wiki/Changes/VisibleCloud .fesco 1146 > > https://fedorahosted.org/fesco/ticket/1146 > > > > #topic #1147 F20 System Wide Change: Web Assets - > > https://fedoraproject.org/wiki/Changes/Web_Assets .fesco 1147 > > https://fedorahosted.org/fesco/ticket/1147 > > > > #topic #1148 F20 System Wide Change: Application Installer - > > https://fedoraproject.org/wiki/Changes/AppInstaller .fesco 1148 > > https://fedorahosted.org/fesco/ticket/1148 > > > > = Open Floor = > > > > For more complete details, please visit each individual ticket. > > The report of the agenda items can be found at > > https://fedorahosted.org/fesco/report/9 > > > > If you would like to add something to this agenda, you can reply > > to this e-mail, file a new ticket at > > https://fedorahosted.org/fesco, e-mail me directly, or bring it up > > at the end of the meeting, during the open floor topic. Note that > > added topics may be deferred until the following meeting. > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.13 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlH5S9QACgkQeiVVYja6o6OhpwCfWaMs5PjVxDI4sGcje2CCyweY > 2lYAn0ggtlPRq56a+SFABKdWLHwnKQes > =HkpT > -END PGP SIGNATURE- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-RRD-Simple] Handle filtering of provides from unversioned doc-dirs from F-20
commit 30a6140f196dcaab25ada4f9f3f59a3e6fb3ba6a
Author: Paul Howarth
Date: Wed Jul 31 18:44:59 2013 +0100
Handle filtering of provides from unversioned doc-dirs from F-20
- Handle filtering of provides from unversioned doc-dirs from F-20
- Don't need to remove empty directories from the buildroot
perl-RRD-Simple.spec | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
---
diff --git a/perl-RRD-Simple.spec b/perl-RRD-Simple.spec
index 9f7223f..f56fffb 100644
--- a/perl-RRD-Simple.spec
+++ b/perl-RRD-Simple.spec
@@ -1,9 +1,9 @@
# Need to tweak provides/requires filters differently if we have rpm 4.9
onwards
-%global rpm49 %(rpm --version | perl -pi -e 's/^.*
(\\d+)\\.(\\d+)\\.(\\d+).*/sprintf("%d.%03d%03d",$1,$2,$3) ge 4.009 ? 1 : 0/e')
+%global rpm49 %(rpm --version | perl -p -e 's/^.*
(\\d+)\\.(\\d+)\\.(\\d+).*/sprintf("%d.%03d%03d",$1,$2,$3) ge 4.009 ? 1 : 0/e')
Name: perl-RRD-Simple
Version: 1.44
-Release: 15%{?dist}
+Release: 16%{?dist}
Summary: Simple interface to create and store data in RRD files
Group: Development/Libraries
License: ASL 2.0
@@ -26,6 +26,10 @@ BuildRequires: perl(Test::Pod::Coverage)
BuildConflicts:perl(Test::Deep)
Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+# Move to unversioned documentation directories from F-20
+# https://fedoraproject.org/wiki/Changes/UnversionedDocdirs
+%global rrd_docdir %{?_pkgdocdir}%{!?_pkgdocdir:%{_docdir}/%{name}-%{version}}
+
%description
RRD::Simple provides a simple interface to RRDTool's RRDs module. This module
does not currently offer the fetch method that is available in the RRDs
@@ -39,10 +43,10 @@ if you do not need to, nor want to, bother defining custom
RRA definitions.
%prep
%setup -q -n RRD-Simple-%{version}
-# Don't want provides/requires from %%{_docdir}
-%global docfilt perl -p -e 's|%{_docdir}/%{name}-%{version}\\S+||'
+# Don't want provides/requires from documentation
+%global docfilt perl -p -e 's|%{rrd_docdir}\\S+||'
# RRD::Simple version should be from distribution version, not svn revision
-%global verfilt perl -pi -e 's/(perl\\(RRD::Simple\\) =) \\d+/\\1 %{version}/'
+%global verfilt perl -p -e 's/(perl\\(RRD::Simple\\) =) \\d+/\\1 %{version}/'
# Apply provides/requires filters
%if %{rpm49}
%global provfilt /bin/sh -c "%{docfilt} | %{__perllib_provides} | %{verfilt}"
@@ -64,7 +68,6 @@ AUTOMATED_TESTING=1 perl Build.PL installdirs=vendor
%install
rm -rf %{buildroot}
./Build install destdir=%{buildroot} create_packlist=0
-find %{buildroot} -depth -type d -exec rmdir {} ';' 2>/dev/null
%{_fixperms} %{buildroot}
%check
@@ -84,6 +87,10 @@ rm -rf %{buildroot}
%{_mandir}/man3/RRD::Simple::Examples.3pm*
%changelog
+* Wed Jul 31 2013 Paul Howarth - 1.44-16
+- Handle filtering of provides from unversioned doc-dirs from F-20
+- Don't need to remove empty directories from the buildroot
+
* Fri Jul 26 2013 Petr Pisar - 1.44-15
- Perl 5.18 rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Mon, Jul 29, 2013 at 05:34:05PM -0400, Simo Sorce wrote: > On Mon, 2013-07-29 at 23:06 +0200, Lennart Poettering wrote: > > Well, the point I am making is that it is wrong to ask userspace to > > handle this. Get the APIs right you expose to userspace. > > If user space assume it can use 'all the space up to 15% from exhausting > space' then it is user space that is wrong to me. > Even w/o thin provisioning you do not want any application to > boundlessly consume terabytes of space just because it happen to sit on > a *big* disk. > Applications may use heuristics to better behave in 'common' situations, > but should limit themselves also on the max space they are going to > consume in general (or better have admin controllable knobs to do so > coupled with reasonable defaults). journald provides configuration knobs to exactly set the limits. But forcing the admin to always configure this is something that should be avoided, and reasonable values that work OK most of the time should be used. Those defaults (15% of available /var/log, 10% free) may not be perfect, but they give reasonable behaviour on various systems, large and small. This is true even on btrfs with 50% overestimate of free space. > > I mean, ultimately for me it doesn't matter I geuss, since you say > > neither the fs/block layer nor userspace should care, but that this is > > the admin's problem, but that really sounds like chickening out to > > me... > > Given the admin is the only one that knows for any given situation what > is more important to him I do not think there is much more you can do. > Sure you can set defaults or what not but there isn't any configuration > that will ever be right short of something that can read minds. > > What you can do is give admin knobs to tweak in user space, as well as > in the kernel. So that applications can limit themselves based on > configuration, lacking those knobs you need to provide mechanisms a la > cgroups that are used to hard limit misbehaving apps that think they are > at an all-you-can-it buffet. Let's say that I'm downloading something in the browser, or creating a iso image in brasero. I think it would be really awful if those applications couldn't tell me that I don't have enough space (without actually exhausting it and hitting a limit), like they can now. So it's not a question of misbehaving. Zbyszek -- they are not broken. they are refucktored -- alxchk -- 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: F20 System Wide Change: Visible Cloud
On Wed, Jul 17, 2013 at 06:08:42PM -0400, Matthew Miller wrote: > On Wed, Jul 17, 2013 at 02:12:03PM -0700, Adam Williamson wrote: > > > So, to put a number on it, does that mean _at_ the change freeze and > > > branch > > > which is "no earlier than 2013-08-06"? > > As things stand, yeah. I think for F19 we actually started doing TCs > > earlier, but certainly by then. > Okay, cool. I wil draft up a minor revision to the existing EC2 test case > and create one in the same vein for OpenStack. https://fedoraproject.org/wiki/QA:Testcase_EC2_AMI_Validation https://fedoraproject.org/wiki/QA:Testcase_OpenStack_Image_Validation -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On 7/31/13 12:08 PM, Chris Murphy wrote: > > On Jul 31, 2013, at 8:32 AM, Mike Snitzer > wrote: > >> But on the desktop the fedora developers need to provide sane >> policy/defaults. > > Right. And the concern I have (other than a blatant bug), is the F20 > feature for the installer to create thinp LVs; and to do that the > installer needs to know what sane default parameters are. I think > perhaps determining those defaults is non-obvious because of my > experience in this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=984236 > > If I'm going to use thinP mostly for snapshots, then that suggests a > smaller chunk size at thin pool creation time; whereas if I have no > need for snapshots but a greater need for provisioning then a larger > chunk size is better. And asking usage context in the installer, I > think is a problem. Quite some time ago I had asked whether we could get the allocation-tracking snapshot niceties from dm-thinp, without actually needing it to be thin. i.e. if you only want the efficient snapshots, a way to fully-provision a "thinp" device. I'm still not sure if this is possible...? I guess I'm pretty nervous about offering actual thin provisioned storage to "average" Fedora users. I'm having nightmares about the "bug" reports already, just based on the likelihood of most users misunderstanding the feature and it's requirements & expected behavior... -Eric > Chris Murphy > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Thursday's FPC Meeting (2013-08-01 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at -MM-DD 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2013-08-01 09:00 Thu US/Pacific PDT 2013-08-01 12:00 Thu US/Eastern EDT 2013-08-01 16:00 Thu UTC <- 2013-08-01 17:00 Thu Europe/London BST 2013-08-01 18:00 Thu Europe/Paris CEST 2013-08-01 18:00 Thu Europe/Berlin CEST 2013-08-01 21:30 Thu Asia/Calcutta IST --new day-- 2013-08-02 00:00 Fri Asia/Singapore SGT 2013-08-02 00:00 Fri Asia/Hong_Kong HKT 2013-08-02 01:00 Fri Asia/Tokyo JST 2013-08-02 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = New business = #topic #324 Poor Packaging:CronFiles guidelines .fpc 324 https://fedorahosted.org/fpc/ticket/324 #topic #325 Temporary bundling exception of yajl library .fpc 325 https://fedorahosted.org/fpc/ticket/325 #topic #326 Bundling exception for python-kapteyn .fpc 326 https://fedorahosted.org/fpc/ticket/326 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: This is a digitally signed message part -- 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: Obsoleting ConsoleKit once and for all
On Tue, 30 Jul 2013 16:28:55 +0200 Christoph Wickert wrote: > Am Montag, den 29.07.2013, 16:37 +0200 schrieb Lennart Poettering: > > On Sun, 28.07.13 13:24, Christoph Wickert > > (christoph.wick...@gmail.com) wrote: > > > > > and by pcmamfm and thunar for > > > handling permissions of removable devices. > > > > I don't know what "pcmamfm" and "thunar" are, but why would they use > > ConsoleKit for that? Can you elaborate? > > thunar and pcmanfm are file managers and require ConsoleKit for > handling removable storage. I'm traveling right now so don't have time to look, but are you sure this is still the case for Thunar? I see no deps, no ck-* functions, and everything seems to work fine here with no ConsoleKit installed. I'll try and investigate more in the next few days when I am back home. kevin signature.asc Description: PGP signature -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
Am 31.07.2013 20:14, schrieb Zbigniew Jędrzejewski-Szmek: > journald provides configuration knobs to exactly set the limits. > But forcing the admin to always configure this is something that > should be avoided, and reasonable values that work OK most of the > time should be used. Those defaults (15% of available /var/log, 10% free) > may not be perfect, but they give reasonable behaviour on various > systems, large and small. This is true even on btrfs with 50% > overestimate of free space you are aware how much 10% of 8 TB are? this is the same way fundamentally broken as the "5% reserved for root" these days you need at least a lot of more fuzzy logic * not more than XXX MB * or vary the percentage depending on the drive size * if /var/log is a dedicated partition *nothing* reserved signature.asc Description: OpenPGP digital signature -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Wed, Jul 31, 2013 at 08:18:52PM +0200, Reindl Harald wrote: > you are aware how much 10% of 8 TB are? So why *not* keep more logs, at least while nothing else is using it? > you need at least a lot of more fuzzy logic > * not more than XXX MB > * or vary the percentage depending on the drive size > * if /var/log is a dedicated partition *nothing* reserved That last, at least, seems reasonable. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Wed, Jul 31 2013 at 1:08pm -0400, Chris Murphy wrote: > > On Jul 31, 2013, at 8:32 AM, Mike Snitzer wrote: > > > But on the desktop the fedora > > developers need to provide sane policy/defaults. > > Right. And the concern I have (other than a blatant bug), is the F20 > feature for the installer to create thinp LVs; and to do that the > installer needs to know what sane default parameters are. I think > perhaps determining those defaults is non-obvious because of my > experience in this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=984236 Hmm, certainly a strange one. But some bugs can be. Did you ever look to see if CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is enabled? Wouldn't explain any dmeventd memleak issues but could help explain slowness associated with mkfs.btrfs ontop of thinp. Anyway, to be continued in the BZ... > If I'm going to use thinP mostly for snapshots, then that suggests a > smaller chunk size at thin pool creation time; whereas if I have no > need for snapshots but a greater need for provisioning then a larger > chunk size is better. And asking usage context in the installer, I > think is a problem. It is certainly less than ideal but we haven't come up with an alternative yet. As Zdenek mentioned in comment#13 of the BZ you referenced, we're looking to do is establish default profiles for at least these 2 use-cases you mentioned. lvm2 has recently grown profile support. We just need to come to terms with what constitutes sufficiently small and sufficently large thinp block sizes. We're doing work to zero in on the best defaults... so ultimately this is still up in the air. But my current thinking for these 2 profiles is: * for performance, use data device's optimal_io_size if > 64K. - this will yield a thinp block_size that is a full stripe on RAID[56] * for snapshots, use data device's minimum_io_size if > 64K. If/when we have the kernel REQ_RESERVE support to prealloc space in the thin-pool it _could_ be that we make the snapshots profile the default; and anything that wanted more performance could use fallocate(). But it is a slippery slope because many apps could overcompensate to always use fallocate()... we really don't want that. So some form of quota might need to be enforced on a cgroup level (once cgroup's reservation quota is exceeded fallocate()'s REQ_RESERVE bio pass down will be skipped). Grafting in cgroup-based policy into DM is a whole other can of worms, but doable. Open to other ideas... Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
How to support new boards?
Is there a wiki page on supporting new boards? I have a BeagleBone Black that I'd prefer to use Fedora on, but the instructions on the wiki all seem to be about how to install pre-made images, not how to create new images. Is there instructions for how to do this anywhere? -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Wed, Jul 31 2013 at 2:38pm -0400, Eric Sandeen wrote: > On 7/31/13 12:08 PM, Chris Murphy wrote: > > > > On Jul 31, 2013, at 8:32 AM, Mike Snitzer > > wrote: > > > >> But on the desktop the fedora developers need to provide sane > >> policy/defaults. > > > > Right. And the concern I have (other than a blatant bug), is the F20 > > feature for the installer to create thinp LVs; and to do that the > > installer needs to know what sane default parameters are. I think > > perhaps determining those defaults is non-obvious because of my > > experience in this bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=984236 > > > > If I'm going to use thinP mostly for snapshots, then that suggests a > > smaller chunk size at thin pool creation time; whereas if I have no > > need for snapshots but a greater need for provisioning then a larger > > chunk size is better. And asking usage context in the installer, I > > think is a problem. > > Quite some time ago I had asked whether we could get the allocation-tracking > snapshot niceties from dm-thinp, without actually needing it to be thin. > > i.e. if you only want the efficient snapshots, a way to fully-provision > a "thinp" device. I'm still not sure if this is possible...? TBD, we could add a "sandeen_makes_thinp_his_bitch" param and if specified (likely for entire pool, but we'll see) it would mean thin volumes allocating from the pool would have their logical address space reserved to be completey contiguous on creation (with all thin blocks flagged in metadata as RESERVED). The actual thin block allocation (zeroing of blocks on first write if configured, etc.) transitions the metadata's block from RESERVED to PROVISIONED. Not yet clear to me that the DM thinp code can be easily adapted to make the thin block allocation 2 staged. But would seem to be a prereq for dm-thinp's REQ_RESERVE support. I'll check with Joe (cc'd) and come back with his dose of reality ;) > I guess I'm pretty nervous about offering actual thin provisioned > storage to "average" Fedora users. I'm having nightmares about the "bug" > reports already, just based on the likelihood of most users misunderstanding > the feature and it's requirements & expected behavior... Heh, you shouldn't be nervous. You can just punt said bugs over the fence right? ;) Mike -- 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: Rebuild of Boost dependees
On Tue, Jul 30, 2013 at 11:15 AM, Paulo César Pereira de Andrade < paulo.cesar.pereira.de.andr...@gmail.com> wrote: > 2013/7/30 Jerry James : > > On Mon, Jul 29, 2013 at 10:01 AM, Petr Machata > wrote: > >> > >> polybori5663365 SCONS: internal error in regular > >> expression engine > > > > > > I will try to figure this one out. > > This should be 32 bit only. > http://bugs.python.org/issue17998 > > It should be possible to workaround the problem in polybori's SConstruct, > just > that the trivial solution does not work, but I did not notice any problems > after > rebuilding python with the patch in the bugs.python.org report... > Neither my python-fu nor my scons-fu is great enough for me to figure out how to work around this problem. Can any python masters on this list see a way to work around the bug? This is https://bugzilla.redhat.com/show_bug.cgi?id=974257 for anybody interested. -- Jerry James http://www.jamezone.org/ -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Jul 31, 2013, at 1:44 PM, Mike Snitzer wrote: > Did you ever look > to see if CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is enabled? It's not enabled in either the regular or debug kernels found in koji. Chris Murphy -- 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: F20 System Wide Change: Visible Cloud
On Wed, 2013-07-31 at 14:18 -0400, Matthew Miller wrote: > On Wed, Jul 17, 2013 at 06:08:42PM -0400, Matthew Miller wrote: > > On Wed, Jul 17, 2013 at 02:12:03PM -0700, Adam Williamson wrote: > > > > So, to put a number on it, does that mean _at_ the change freeze and > > > > branch > > > > which is "no earlier than 2013-08-06"? > > > As things stand, yeah. I think for F19 we actually started doing TCs > > > earlier, but certainly by then. > > Okay, cool. I wil draft up a minor revision to the existing EC2 test case > > and create one in the same vein for OpenStack. > > https://fedoraproject.org/wiki/QA:Testcase_EC2_AMI_Validation > https://fedoraproject.org/wiki/QA:Testcase_OpenStack_Image_Validation Thanks! Usually I do drafts in my personal space and move them to the 'official' space after time for review and comment, but it's no biggie. Could you send a mail to test@ (where we usually do test case review) explaining that you've created these test cases and any notes that are appropriate, and asking for feedback? I've sent out a few test case drafts lately, you can use those mails as a guide: https://lists.fedoraproject.org/pipermail/test/2013-July/117196.html https://lists.fedoraproject.org/pipermail/test/2013-July/117198.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-07-31)
On Wed, 2013-07-31 at 13:44 -0400, Jaroslav Reznik wrote: > - Original Message - > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Today's FESCo meeting is *CANCELED* due to lack of quorum. FESCo > > members are advised to vote in the FESCo Trac. > > I'd like to ask to vote for the Schedule ticket specifically as the > next FESCo meeting is after currently scheduled F20 Branch date. We (QA) would also really like the status of the Visible Cloud change in particular to be decided ASAP. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Wed, 2013-07-31 at 11:52 +0200, Zdenek Kabelac wrote: ... > ThinP should be configured in a way that admin is able to extend pool to > honour promised space if really needed. It's not a good idea, to provision > 1EB > if you have at most just 1TB disk and then you expect you will have no > problems when someone fallocate() 500TB. > > I.e. if someone is using iSCSI disc array with 'hw' thin provisioning > support, there is no scsi command to provision space - it's admin's work to > ensure there is enough disc space to keep up with user demands Oops, Zdenek is likely repeating a mis-statement I made about the SCSI Standard on a call yesterday. I just checked and I was wrong - the latest draft of the Standard does provide a way to pre-provision space. Sorry - I should have checked before speaking. In March 2010 the SCSI committee added the concept of "anchored thin provisioning" to the (proposed) SCSI Block Commands – 3 (SBC-3) Standard. This allows a logical block to be in one of three states: mapped, deallocated, or anchored. A write command that specifies an anchored LBA does not require allocation of additional LBA mapping resources for that LBA. A write command that specifies a deallocated LBA may require allocation of LBA mapping resources. This change was proposed by David Black from EMC. The justification is reflects our discussion: "There is extensive experience with this sort of resource preallocation mechanism in filesystems, as most physical filesystems are effectively thin provisioned courtesy of the way that file space allocation works. In that domain, this sort of preallocation mechanism is useful and used selectively (e.g., the fallocate() primitive in Linux and Unix systems). In this context, SCSI anchored functionality can be viewed as extending filesystem notions of preallocation down to include SCSI thin provisioning.". So, 1) others have seen the need for pre-allocation in thinp environments, 2) hardware will eventually show up that implements it, 3) it appears as though the extension to fallocate that Mike suggested is worth investigating, 4) if we do this, we will want to add the concept to LVM thinp, and 5) to the plumbing in Linux SCSI so we can pass it to capable hardware. Tom -- 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: How to support new boards?
On Wed, Jul 31, 2013 at 3:59 PM, Brendan Long wrote: > Is there a wiki page on supporting new boards? I have a BeagleBone Black > that I'd prefer to use Fedora on, but the instructions on the wiki all > seem to be about how to install pre-made images, not how to create new > images. Is there instructions for how to do this anywhere? You should probably ask on a...@lists.fedoraproject.org. josh -- 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: How to support new boards?
On Wed, Jul 31, 2013 at 12:59 PM, Brendan Long wrote: > Is there a wiki page on supporting new boards? I have a BeagleBone Black > that I'd prefer to use Fedora on, but the instructions on the wiki all > seem to be about how to install pre-made images, not how to create new > images. Is there instructions for how to do this anywhere? > If you're specifically talking about ARM devices, I strongly encourage you to join the Fedora ARM mailing list, IRC channel, and weekly chats. I know several of the other members of the ARM Special Interest Group have the BeagleBone Black, and are working on making Fedora run well on it. -- Jared Smith -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Wed, 2013-07-31 at 13:38 -0500, Eric Sandeen wrote: > On 7/31/13 12:08 PM, Chris Murphy wrote: > > > > On Jul 31, 2013, at 8:32 AM, Mike Snitzer > > wrote: > > > >> But on the desktop the fedora developers need to provide sane > >> policy/defaults. > > > > Right. And the concern I have (other than a blatant bug), is the F20 > > feature for the installer to create thinp LVs; and to do that the > > installer needs to know what sane default parameters are. I think > > perhaps determining those defaults is non-obvious because of my > > experience in this bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=984236 > > > > If I'm going to use thinP mostly for snapshots, then that suggests a > > smaller chunk size at thin pool creation time; whereas if I have no > > need for snapshots but a greater need for provisioning then a larger > > chunk size is better. And asking usage context in the installer, I > > think is a problem. > > Quite some time ago I had asked whether we could get the allocation-tracking > snapshot niceties from dm-thinp, without actually needing it to be thin. > > i.e. if you only want the efficient snapshots, a way to fully-provision > a "thinp" device. I'm still not sure if this is possible...? > > I guess I'm pretty nervous about offering actual thin provisioned > storage to "average" Fedora users. I'm having nightmares about the "bug" > reports already, just based on the likelihood of most users misunderstanding > the feature and it's requirements & expected behavior... There was some discussion in #anaconda yesterday about making it available only via custom partitioning rather than the Installation Options dropdown, IIRC. That has the effect of denoting it as an 'advanced feature' and requiring more expertise on the part of the user to set it up. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora ARM Weekly Status Meeting Minutes 2013-07-31
Thanks to those that were able to join us for the status meeting today, for those unable the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-31/fedora-meeting-1.2013-07-31-19.30.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-31/fedora-meeting-1.2013-07-31-19.30.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-31/fedora-meeting-1.2013-07-31-19.30.log.html Paul -- 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: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Jul 31, 2013, at 12:38 PM, Eric Sandeen wrote: > > i.e. if you only want the efficient snapshots, a way to fully-provision > a "thinp" device. I'm still not sure if this is possible…? […] > > I guess I'm pretty nervous about offering actual thin provisioned > storage to "average" Fedora users. I'm having nightmares about the "bug" > reports already, just based on the likelihood of most users misunderstanding > the feature and it's requirements & expected behavior… So possibly the installer should be conservative about how thin the provisioning is; otherwise I'm imagining inadequately provisioned thinp LV, while also using the rollback feature [1]. [1] https://fedoraproject.org/wiki/Changes/Rollback Chris Murphy -- 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: [Yum-devel] dnf-0..3.10
On Mon, 2013-07-22 at 15:26 +0200, Ales Kozumplik wrote: > Hello, > > I've pushed new DNF version to F19 [1] and Rawhide today. There's only > little changes but the default value for repos' skip_if_unavailable has > changed and is enabled now. This is because recently an ailing Dropbox > repo has made many fine DNF processes end too soon for no good reason [3]. Again I would caution you against just blindly changing defaults to be incompatible with yum ... even if the yum defaults are bad, every incompatibility incurs a cost for all users (and it will exist as long as yum and dnf are being used ... so like 10 years from now). At worst speak with Zdenek about changing yum's defaults in future Fedora versions, although even that's still going to be a problem for most users. In this case there's a reason skip_if_unavailable defaults to off, with it on by default most of the package managers output is vastly more suspect due to having no assurance about which repos. were actually used to do the operation. And this is 100 worse for any code that does things like "repo. X can't have packages that exist in repo. Y" Also a lot of errors become "silent" errors (so things are slow and don't work well instead of explicitly saying: foo repo. is broken). Indeed are the dropbox repos. likely to be broken, or would someone fix them if they knew? Should users have them disabled by default and only use --enablerepo occasionally? Should they not be implemented as a direct repo. at all? -- 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: Failures of noarch package builds on ARM (Re: ARM Status)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 31 Jul 2013 11:25:45 +0100 "Daniel P. Berrange" wrote: > On Sun, Jul 28, 2013 at 03:05:34PM -0500, Dennis Gilmore wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > hi all, > > > > I have imported ARM into primary and enabled armv7hl in the arches > > to be built. right now the KDE stack is not entirely built and > > brought in due to > > https://bugzilla.redhat.com/show_bug.cgi?id=988114 as soon as it is > > resolved we will get everything fixed and brought in. at that point > > arm will be added to the nightly composes. > > I've just attempted to build mingw-libvirt (which is noarch) in > rawhide and was (unlucky?) that it got scheduled on an ARM builder. > The build failed with > > checking build system type... Invalid configuration > `armhfp-redhat-linux-gnu': machine `armhfp-redhat' not recognized > > http://koji.fedoraproject.org/koji/taskinfo?taskID=568 this is because on noarch builds koji sets the target to yums basearch. in the case or armhfp the basearch is invalid according to autoconf. arm and armv* are valid, I have patched koji to use arm for noarch packages where the basearch is armhfp. this wasnt seen before because noarch only builds were directly imported since they are supposed to run anywhere, it just didn't make sense to rebuild them. but its fixed in production now. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlH5kbcACgkQkSxm47BaWffzhACfdJDiv0hWqIOEDViGurnlano7 qZsAoLn7FVVgDIGIPxi5dnbtdUZyVxq5 =pMMx -END PGP SIGNATURE- -- 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: [Yum-devel] dnf-0..3.10
Also, consider cases where repository priorities are in use; a lower-priority repo that's unreachable may cause unexpected/damaging results for the administrator in cases where there's a package version mismatch. (This is actually a real case for me: in an environment I work in, a lower-priority repository contains packages which supersede their counterparts in higher-priority repositories, occasionally at lower version numbers. A transient error here could potentially cause the installation of higher-version RPMs from the higher-priority repository; once the error was corrected, a downgrade would have to be manually kicked off.) I'd strongly urge you to consider the side-effects of this change. On Wed, Jul 31, 2013 at 3:06 PM, James Antill wrote: > On Mon, 2013-07-22 at 15:26 +0200, Ales Kozumplik wrote: > > Hello, > > > > I've pushed new DNF version to F19 [1] and Rawhide today. There's only > > little changes but the default value for repos' skip_if_unavailable has > > changed and is enabled now. This is because recently an ailing Dropbox > > repo has made many fine DNF processes end too soon for no good reason > [3]. > > > Again I would caution you against just blindly changing defaults to be > incompatible with yum ... even if the yum defaults are bad, every > incompatibility incurs a cost for all users (and it will exist as long > as yum and dnf are being used ... so like 10 years from now). At worst > speak with Zdenek about changing yum's defaults in future Fedora > versions, although even that's still going to be a problem for most > users. > > > In this case there's a reason skip_if_unavailable defaults to off, with > it on by default most of the package managers output is vastly more > suspect due to having no assurance about which repos. were actually used > to do the operation. And this is 100 worse for any code that does things > like "repo. X can't have packages that exist in repo. Y" > > Also a lot of errors become "silent" errors (so things are slow and > don't work well instead of explicitly saying: foo repo. is broken). > Indeed are the dropbox repos. likely to be broken, or would someone fix > them if they knew? Should users have them disabled by default and only > use --enablerepo occasionally? Should they not be implemented as a > direct repo. at all? > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Ed Marshall Felix qui potuit rerum cognoscere causas. http://esm.logic.net/ -- 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: Rebuild of Boost dependees
On Tue, Jul 30, 2013 at 5:02 PM, Petr Machata wrote: > fritzing5677658 no matching function for call to > 'qMax(double&, qreal)' > This popped up the last time Fritzing was built on ARM; I have a pending update for this package anyway, so I'll catch this at the same time. -- Ed Marshall Felix qui potuit rerum cognoscere causas. http://esm.logic.net/ -- 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: Schedule for Thursday's FPC Meeting (2013-08-01 16:00 UTC)
Hi, On Thu, Aug 1, 2013 at 12:29 AM, James Antill wrote: > Following is the list of topics that will be discussed in the FPC > meeting Thursday at -MM-DD 16:00 UTC in #fedora-meeting-1 on > irc.freenode.net. > > Local time information (via. rktime): > > 2013-08-01 09:00 Thu US/Pacific PDT > 2013-08-01 12:00 Thu US/Eastern EDT > 2013-08-01 16:00 Thu UTC <- > 2013-08-01 17:00 Thu Europe/London BST > 2013-08-01 18:00 Thu Europe/Paris CEST > 2013-08-01 18:00 Thu Europe/Berlin CEST > 2013-08-01 21:30 Thu Asia/Calcutta IST > --new day-- > 2013-08-02 00:00 Fri Asia/Singapore SGT > 2013-08-02 00:00 Fri Asia/Hong_Kong HKT > 2013-08-02 01:00 Fri Asia/Tokyo JST > 2013-08-02 02:00 Fri Australia/Brisbane EST > > Links to all tickets below can be found at: > > https://fedorahosted.org/fpc/report/12 > > = New business = > > #topic #324 Poor Packaging:CronFiles guidelines > .fpc 324 > https://fedorahosted.org/fpc/ticket/324 > > #topic #325 Temporary bundling exception of yajl library > .fpc 325 > https://fedorahosted.org/fpc/ticket/325 > > #topic #326 Bundling exception for python-kapteyn > .fpc 326 > https://fedorahosted.org/fpc/ticket/326 > > When will .fpc 321 be considered as New Business or was it discussed already in last meeting? Regards, Parag. -- 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: [Yum-devel] dnf-0..3.10
On 01/08/13 02:36, Ed Marshall wrote: > Also, consider cases where repository priorities are in use; a > lower-priority repo that's unreachable may cause unexpected/damaging > results for the administrator in cases where there's a package version > mismatch. > regarding priorities/costs, I filed an RFE bug some time ago: https://bugzilla.redhat.com/show_bug.cgi?id=967798 -- Matthias Runge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
