Re: Renaming the cloud-utils package
On Thu, Feb 20, 2014 at 11:46 AM, Matthias Runge mru...@matthias-runge.de wrote: On Wed, Feb 19, 2014 at 06:18:30PM +0100, Juerg Haefliger wrote: Hi, I'm trying to figure out if it makes sense to rename the cloud-utils (sub-)package for EPEL7 and F21. Upstream (Ubuntu) used to have a single package named cloud-utils which we decided to split up into two packages, cloud-utils and cloud-utils-growpart. The reason being that cloud-utils pulls in a lot of additional packages which is sub-optimal for cloud images. Now Ubuntu followed suit and provides cloud-guest-utils and cloud-image-utils sub-packages. My question is if we should align with Ubuntu and rename our packages or stick with what we have? I admit I'm ignorant to all the ramifications of renaming a package but from a user's perspective it's definitely a benefit if package names match across distros. It makes sense to follow upstream here. The process is documented here[1]. I'd inform the cloud WG, because they might be interested ;-) My case is slightly different: What I have today is the cloud-utils repo, which produces two packages: cloud-utils and cloud-utils-growpart (which contains only the growpart script plus man page). What I want is to keep the cloud-utils repo but create a metadata package cloud-utils plus two sub-packages cloud-image-utils and cloud-guest-utils. cloud-guest-utils will contain the growpart stuff plus another small script to match upstream. cloud-image-utils will replace the former cloud-utils package and the new cloud-utils package will simply require cloud-image-utils and cloud-guest utils. Am I making sense? :-) I can understand going through a new package review process but I wouldn't need a new git repo, or would I? ...Juerg Matthias [1] https://fedoraproject.org/wiki/Package_Renaming_Process -- Matthias Runge mru...@matthias-runge.de -- 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
EPEL epel beta report: 20140224 changes
Compose started at Mon Feb 24 08:15:02 UTC 2014 Broken deps for x86_64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.x86_64 requires mod_python chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-rsa docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma globus-gram-job-manager-pbs-1.6-7.el7.x86_64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.x86_64 requires gridengine koji-vm-1.8.0-2.el7.noarch requires python-virtinst lxc-templates-0.9.0-3.el7.x86_64 requires dpkg lxc-templates-0.9.0-3.el7.x86_64 requires debootstrap lxc-templates-0.9.0-3.el7.x86_64 requires busybox mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nagios-plugins-nrpe-2.15-1.el7.x86_64 requires nagios-plugins openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg perl-qpid-0.24-2.el7.x86_64 requires qpid-cpp-client = 0:0.24 perl-qpid-0.24-2.el7.x86_64 requires perl(qpid_messaging) phoronix-test-suite-4.8.6-1.el7.noarch requires php-fpdf plowshare-0.9.4-0.46.20140112git.el7.noarch requires caca-utils postgrey-1.34-12.el7.noarch requires perl(Net::Server::Multiplex) postgrey-1.34-12.el7.noarch requires perl(Net::Server::Daemonize) postgrey-1.34-12.el7.noarch requires perl(Net::Server) postgrey-1.34-12.el7.noarch requires perl(BerkeleyDB) python-qpid_messaging-0.24-3.el7.x86_64 requires qpid-cpp-client(x86-64) = 0:0.24 python-social-auth-0.1.19-1.el7.noarch requires python-requests-oauthlib = 0:0.3.0 python-social-auth-0.1.19-1.el7.noarch requires python-oauthlib = 0:0.3.8 qt4pas-2.5-3.el7.x86_64 requires fpc-src racoon2-20100526a-27.el7.x86_64 requires perl-Getopt-Simple rubygem-gssapi-1.1.2-3.el7.noarch requires rubygem(ffi) = 0:1.0.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-mocks) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-expectations) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-core) = 0:2.14.1 spectrwm-2.4.0-2.el7.x86_64 requires xlockmore spectrwm-2.4.0-2.el7.x86_64 requires dmenu Broken deps for ppc64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.ppc64 requires mod_python chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc cloud-init-0.7.2-8.el7.noarch requires python-requests cloud-init-0.7.2-8.el7.noarch requires dmidecode docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-rsa docker-registry-0.6.5-1.el7.noarch requires python-requests docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma fedmsg-0.7.6-2.el7.noarch requires python-requests globus-gram-job-manager-pbs-1.6-7.el7.ppc64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.ppc64 requires gridengine httpie-0.8.0-1.el7.noarch requires python-requests koji-vm-1.8.0-2.el7.noarch requires python-virtinst lxc-templates-0.9.0-3.el7.ppc64 requires dpkg lxc-templates-0.9.0-3.el7.ppc64 requires debootstrap lxc-templates-0.9.0-3.el7.ppc64 requires busybox mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nagios-plugins-nrpe-2.15-1.el7.ppc64 requires nagios-plugins
Re: Summary/Minutes from today's FESCo Meeting (2014-02-19)
On 02/19/2014 08:57 PM, Tomas Mraz wrote: * Open floor (t8m, 19:45:44) * AGREED: FESCo expects the Tech specs/docs from working groups by March 3rd at the latest (+7, -0, 0:0) (t8m, 19:50:38) * ACTION: t8m will update the weekly reports ticket with this request (t8m, 19:53:08) Env and Stacks WG are dependent on requirements from 3 products, so we probably can't deliver on 3rd March. Marcela -- 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: exclude people from giving karma?
Am 24.02.2014 04:59, schrieb Kevin Kofler: Reindl Harald wrote: how can people pretend installation went smoothly, no issue detected during basic document manipulation for packages which are not installable at all due dependencie problems? Indeed, people giving +1 after manually installing dependencies (!!!) from Koji (for a package that is itself already in updates-testing, so (obviously!) the dependencies MUST be AT LEAST in updates-testing at the time of testing for the update to be valid!) should be banned from Bodhi. That said, may I remind you that you have recently given a +1 to a very broken kdelibs update (kdelibs-4.11.3-6.fc19, which was causing crashes during autostart)? (Thankfully, the update didn't make it to stable anyway; we replaced it with a fixed build.) So please also be careful with your own +1 votes. :-) that must have been end 2013 and since i don't remember a 35 chars password that leads to my easy-karma.sh echo's the pwd for the clipboard that karma was given out of a running KDE session 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: tcllib update
Thanks. Fixed. 1.15-2.fc21 didn't fix the file conflict problem. file /usr/share/man/mann/fifo.n.gz from install of tcllib-1.15-2.fc21.noarch conflicts with file from package memchan-2.3-4.fc20.i686 -- 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: Java headless bugs
Jerry James loganje...@gmail.com writes: I've got a few comments and questions about the recently filed bugs asking us to switch from Requires: java to Requires: java-headless. First, the bugs list some web pages to view for more information. Number two on that list is this: https://fedoraproject.org/wiki/Packaging:Java\#BuildRequires_and_Requires which has a really unfortunate backslash in it. People clicking on that link get a sorry, no such page message from the web server. It should have been this: https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires Yup, my bad. I guess this was added automatically when I was copy-pasting from wiki where I was preparing the message. The tracking bug has correct link at least... Second, the bugs talk about this as a proposed guidelines change, yet https://fedoraproject.org/wiki/Packaging:Java now talks about it. Doesn't that mean that this is an official guideline, not a proposed change to the official gudelines? I believe you misread it: See tracking bug #1067528 or Headless Java change proposal[1] and Java Packaging guidelines[2] for more details about this change. The work proposal was wrt Headless Java change. Fedora doesn't usually require immediate change to all packages in repositories with each guideline change. However for Headless Java change to have any effect most packages have to migrate. I re-read the bugs and I don't see how it could be read as proposed guidelines change. I had a few people read the messages before filing the bug and it seemed to be OK as well. In any case, yes the official guideline is prefer java-headless if your library/app can use it. Sorry for the confusion. Third, developers are offered two options in those bugs: (1) don't do anything and an automatic tool will make the change for you on or after March 17, or (2) make the change to java-headless yourself. I have one package for which I need a third option: tell the automated tool that this bug was filed in error, the package really doesn't work with java-headless, and don't touch the package. I realize that I can mark the bug as assigned and leave it open indefinitely, but I'd rather have some option for closing the bug, please. Quoting from the bugreport: Automated tool will not touch bugs that are not in NEW state. If you close the bug (whatever reason) the automated tool will not touch your package(s). I guess I should have added close as valid way to avoid it. Slightly off-topic: fedora-review is telling packagers NOT to add Requires: jpackage-utils to javadoc subpackages because that is added automatically, but I see no mention of this on https://fedoraproject.org/wiki/Packaging:Java. Guidelines state that package must have R: jpackage-utils because it contains filesystem (/usr/share/javadoc directory). If the requires is generated automatically all the better but that's not the guidelines scope IMO. I don't see this as much of a problem. Guidelines are there to ensure packages have proper requires. Tooling can improve faster than guidelines. It's not breaking anything and f-r is a guidance tool. It's not guaranteed to comply with guidelines 100%, maintainers should know guidelines in any case and behave appropriately :-) Basically it boils down to understanding why some f-r check fails. We try to point out potential improvements/fixes and sometimes the suggestions might be incorrect. For example if you wanted to keep the same package on EPEL6 and Fedora where EPEL6 wouldn't generate the jpackage-utils requires. Hope this clears up everything, if not drop by #fedora-java IRC -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpxle4fqp5VR.pgp 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: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
From: awill...@redhat.com Date: 02/21/2014 17:05 Subject: Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs Sent by: devel-boun...@lists.fedoraproject.org On Fri, 2014-02-21 at 16:38 -0500, john.flor...@dart.biz wrote: With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex. Everything should be made as simple as possible, but not simpler. I don't think that precept applies very well to this area. The problem is that there are - and this is probably *literal*, not a rhetorical flourish - millions of Special Little Use Cases like yours (the one below, snipped for brevity) out there. *You* want it to be easy to skip /home. *She* wants it to be easy to resize a Slackware install. *That guy* wants to use btrfs. *My cat* likes RAID. It is becoming very, very clear that we just cannot undertake to support them all and guarantee that they are all going to work in a release. It's just _too much work_. Everyone agrees that it would be nice if we could, but then everyone agrees that it'd be nice if I had a solid gold toilet. Brr... no thanks. Well okay, I'd take one for the monetary value. :-) Some nice things just don't happen. We do not have the resources to be in the business of writing the world's biggest disk configuration tool and guaranteeing that it'll never go wrong, which isn't *quite* what we're currently trying to do, but it's not far from it. It's worth trying some other installers out, just to reset your expectations. Have you seen the level of flexibility you get from Ubuntu's interactive installer? Windows'? OS X's? Thank God no. I last touched Ubuntu about 7 years ago. The early days of FC were so not the RHL (e.g. 7.3) that I'd loved so much. But then Ubuntu left me lacking in community. I filed so many bugs that never received a single response. The last time I installed Windows it required something like 20 1.4MB floppies (and that was probably the best part of the whole experience). I've only *used* a Mac twice, once with the originals back in the 80s(?) and again in the 90s -- I've never installed any Apple OS. Too damned different for this old dog. I appreciate your QA angle here. Every condition in a code path leads to exponential growth in testing. And development. This isn't just a QA problem. We do not have the development resources to commit to all this stuff working reliably every six months. Here's where you lost me. Yes, anaconda is going through a rewrite, but shouldn't all development be incremental improvement. You make it sound like it has to be gutted and redone every release. IMHO, nothing kills corner cases like polymorphism. Remove the conditions and you remove the dark corners where bugs like to hide. However, when I have my admin hat on, I want flexibility. I love LVM for that reason. However, if I'm setting up simple VMs whose backend storage resides in a LV, I have no need or desire for LVM within the VM. Does it hurt you to get it, though? Only in the sense you snipped out: resizing w/o LVM is much simpler when disk is virtual, there's just fewer steps. As I stated though, on the host I want/need LVM because in the physical world, LVM makes life way more easier. Yeah, I can live with it in all cases, but then I'm just as likely to do a complete reinstall of the VM as to resize the undersized file system. However, that's only practical because puppet is doing all the dirty work. Really my whole problem is MY problem though. I just have committed to the time of completely automating kickstart script generation and application. The GUI installer has been kind enough to me that I always seem to have higher priorities (like keeping all my services running atop the latest Fedora). -- John Florian -- 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: [Fedora-packaging] May I file 1000 bugs aka upstream test suite tracking
On Fri, Feb 21, 2014 at 04:16:59PM +0100, Dominik 'Rathann' Mierzejewski wrote: 2) Report packages which *don't* have any test suites at all. Could you provide the rationale for 2? Why do you want to do it and what does Fedora gain by doing it? Better code quality, less risk of regressions, easier automatic QA. I think that this is a good initiative, and absolutely fits with something Fedora can and should help with -- but I also agree that bugzilla probably isn't the best place to track it. (It's kind of a shame, though, because a bug tracker would be nicer than a wiki page. We just don't have the right kind of flexiblity in our bugzilla setup to do it.) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.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: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
From: li...@colorremedies.com To: Bruno Wolff III br...@wolff.to Date: 02/22/2014 17:38 Subject: Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs Sent by: devel-boun...@lists.fedoraproject.org On Feb 22, 2014, at 9:39 AM, Bruno Wolff III br...@wolff.to wrote: On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy li...@colorremedies.com wrote: The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install. I'm mainly suggesting a decoupling of all of this effort from an installation only context, so that it can be used to create and modify storage stacks without installing an OS. I don't particularly care how it manifests - separate app, or a spoke within the current app. Communicating the layout can be done with a fstab-like metadata file. If there's no inclination to do this for a much broader use case, then why wedge so much capability and effort into a narrow installer-only use case? Bootable raid6 and raid4?? I actually like that idea of decoupling them. It would be good to see more of the *nix tradition here, do ONE thing and do it very well. Of course we'd need the two things (storage stack manager and installer) and the fun would be in making them appear seamless. -- John Florian -- 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: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Sat, Feb 22, 2014 at 03:37:40PM -0700, Chris Murphy wrote: On Feb 22, 2014, at 9:39 AM, Bruno Wolff III br...@wolff.to wrote: On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy li...@colorremedies.com wrote: The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install. I'm mainly suggesting a decoupling of all of this effort from an installation only context, so that it can be used to create and modify storage stacks without installing an OS. I don't particularly care how it manifests - separate app, or a spoke within the current app. Communicating the layout can be done with a fstab-like metadata file. If there's no inclination to do this for a much broader use case, then why wedge so much capability and effort into a narrow installer-only use case? Bootable raid6 and raid4?? Decoupling can't happen given the hard requirement we have on supporting a wide range of storage configurations. Linux in general has far too many options in this area and everyone's corner case or configuration is most important. So, just to chime in on one of these threads, I can speak to what we are working on in the installer camp right now: 1) Storage configuration and management outside of anaconda. The storage library was broken out as blivet and is growing to support use cases outside of the installer environment. This will open the door to doing things like using the storage UI in anaconda as a standalone management app (as an idea, for example). 2) Supporting alternative partitioning UI projects (both inside and outside of the installer). A number of very quiet people have asked about the feasability of creating another storage configuration UI in the installer. We absolutely do not have the workforce to support multiple storage configuration frontends, but if you want to explore that on your own, feel free. We encourage people to build on top of our blivet library as we have done, but the UI can be whatever you make it. In fact, the more people that try this will probably learn that storage configuration is a highly complicated and political topic. :) 3) Spoke development through our addon API. One thing I have noticed through the posts from Fedora working groups is the request for installation specifics. That's understandable given that the whole idea of the working groups finally admitted that we have multiple target use cases. Anaconda is positioned now to facilitate this through the addon API. Anaconda can grow spokes via plugins. We have a developer guide and the past two DevConf events in Brno have had presentations on how to write an addon for anaconda. With an addon you can: a) Add a new spoke to the installer. b) Add a new text mode spoke. c) Add a kickstart command. d) Add an initial-setup (firstboot) spoke. And I will point out here that initial-setup in this context means the thing we wrote to replace our aging firstboot program. initial-setup is essentially the second hub in anaconda that runs when you first boot up the computer. It is not to be confused with gnome-initial-setup. And that's sort of the high level stuff. If you have any questions you want to ask in this area, I am happy to talk one on one or in a time-bounded meeting. I, unfortunately, do not have the time, patience, or intestinal fortitude to participate in the working group email threads. I can only skim them occassionally. I saw this stuff and just wanted to chime in. Thanks, -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- 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: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
- Original Message - On Fri, 2014-02-21 at 17:08 +0100, Phil Knirsch wrote: Installer is still a hot topic, but thats nothing we could resolve during our meeting and which might have to be brought up with FESCO again. So, as cmurf has been trying to point out on desktop@ , we (QA) have some concerns in this area too, and I know the installer team is open to the idea of at least simplifying the non-custom partitioning path to some extent. This is an extremely complex topic area, though, and it may be tricky to get the right things done if multiple teams are considering it in different contexts in different meetings. It would probably be a Very Good Idea to get everyone with an interest - at least anaconda team, the product WGs (except possibly Cloud, depending on whether they intend to use anaconda in their deliverables at all), base WG, and fesco - together in some way to talk about it. devconf would've been great but it already happened. Flock would be great but it's too late. Should we try to set up some kind of special meeting / list / etherpad / wikipage / *something* where we can all talk it over? Well, the question is if installer changes are short term goals or more long terms and before trying to setup any meeting, it would be nice to collect more data from other groups. So personally, I'd say Flock would be great opportunity to discuss it but on the other hand, it's always nice to be prepared for such conversation. The other groups Tech Spec should be available within a week, then let's try to look for overlapping pieces and I'm definitely volunteer to work on it. Once we have it, it's going to be a good time to discuss details and as Base, we should incorporate it to our Base design. 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: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
- Original Message - On Sat, Feb 22, 2014 at 03:37:40PM -0700, Chris Murphy wrote: On Feb 22, 2014, at 9:39 AM, Bruno Wolff III br...@wolff.to wrote: On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy li...@colorremedies.com wrote: The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install. I'm mainly suggesting a decoupling of all of this effort from an installation only context, so that it can be used to create and modify storage stacks without installing an OS. I don't particularly care how it manifests - separate app, or a spoke within the current app. Communicating the layout can be done with a fstab-like metadata file. If there's no inclination to do this for a much broader use case, then why wedge so much capability and effort into a narrow installer-only use case? Bootable raid6 and raid4?? Decoupling can't happen given the hard requirement we have on supporting a wide range of storage configurations. Linux in general has far too many options in this area and everyone's corner case or configuration is most important. Well, as Fedora.next aims pretty much on productization and we'd like to set higher bar for these products, I think we can limit these everyone's corner case configuration and focus on what's really needed for our main products. And I understand, this is really more politics than technical issue and we're right in this politics time of Fedora.next - a good time to rethink what we do now. Of course the last but not least question is manpower of your team. There's possibility that if we would be able to simplify blocking paths in installer, we could get to the point there would be more time and will to touch proposed ideas... 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
Agenda for Env-and-Stacks WG meeting (2014-02-25)
WG meeting will be at 16:00 UTC in #fedora-meeting on Freenode.
== Topic ==
# additional repository
fedora-{incubator,ugly}
* better name than ugly based on content of repo
* github-like frontend for copr
* discuss policies/procedures for accepting copr repo
#SCL in Fedora
* base on needs for products
* FPC - what's needed now
See you tomorrow,
Marcela
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unretiring NDOUtils
Hello, I would like to unretire NDOUtils in Fedora, I'm currently using it at work. NDOUtils was orphaned in Fedora in 2012 [1], but since the EPEL 5 6 branches cannot be retired, those branches were still there. The previous owner gave the branch ownership to me, so I'm missing only the Fedora branches. Following the procedure for unretiring packages [2] I've created a review for the package: https://bugzilla.redhat.com/show_bug.cgi?id=1069259 Thanks regards, --Simone [1] https://lists.fedoraproject.org/pipermail/devel/2012-February/162171.html [2] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers https://lists.fedoraproject.org/pipermail/devel/2012-February/162171.html -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.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
[Owner-change] Fedora packages ownership change
Change in ownership over the last 168 hours === 8 packages were orphaned ghc-IOSpec [devel,f20] was orphaned by petersen A pure specification of the IO monad https://admin.fedoraproject.org/pkgdb/acls/name/ghc-IOSpec Perlbal [EL-5] was orphaned by lbazan Reverse-proxy load balancer and webserver https://admin.fedoraproject.org/pkgdb/acls/name/Perlbal pidgin-rhythmbox [devel,f19,f20] was orphaned by nosnilmot Rhythmbox plugin for Pidgin https://admin.fedoraproject.org/pkgdb/acls/name/pidgin-rhythmbox dzen2 [EL-6] was orphaned by cassmodiah A general purpose messaging and notification program https://admin.fedoraproject.org/pkgdb/acls/name/dzen2 libev [EL-6,epel7] was orphaned by cassmodiah High-performance event loop/event model with lots of features https://admin.fedoraproject.org/pkgdb/acls/name/libev nx [f19] was orphaned by limb Proxy system for X11 https://admin.fedoraproject.org/pkgdb/acls/name/nx cleanfeed [devel,f19,f20] was orphaned by rrakus A spam filter for Usenet news servers. https://admin.fedoraproject.org/pkgdb/acls/name/cleanfeed mysqltuner [devel,f19] was orphaned by scop MySQL high performance tuning script https://admin.fedoraproject.org/pkgdb/acls/name/mysqltuner 44 packages unorphaned -- zeenix unorphaned : gnome-disk-utility [devel,f20] cicku unorphaned : fife [devel,f19,f20] petersenunorphaned : ghc-IOSpec [devel,f19,f20] kevin unorphaned : greybird [devel] filiperossetunorphaned : metadata-extractor [f20] cicku unorphaned : i3lock [EL-6,f19] auchytilunorphaned : brainfuck [f20] cicku unorphaned : libowfat [EL-5,devel,f20] cicku unorphaned : gengetopt [devel,f20] filiperossetunorphaned : umph [devel,f19,f20] auchytilunorphaned : CUnit [f20] cicku unorphaned : perl-AnyEvent-I3 [EL-6,devel,f19,f20] cicku unorphaned : florence [EL-6,f19,f20] lbazan unorphaned : opentracker [EL-6,devel,f20] petersenunorphaned : ghc-ForSyDe [f19,f20] petersenunorphaned : ghc-parameterized-data [devel,f19,f20,f20] psabata unorphaned : tabbed [devel,f19,f20] cicku unorphaned : libsilc [devel,f19,f20] petersenunorphaned : ghc-logict [devel,f19,f20] aledvinkunorphaned : authd [devel,f19,f20] cicku unorphaned : surf [f19] filiperossetunorphaned : vrq [devel,f19,f20] phatina unorphaned : gperf [devel,f19,f20] petersenunorphaned : ghc-HSH [devel,f19,f20] cassmodiah unorphaned : i3 [EL-6,devel,f19,f20] jsynacekunorphaned : pidgin [devel,f19,f19,f20,f20] filiperossetunorphaned : stratagus [devel,f19,f20] cicku unorphaned : i3-ipc [EL-6,devel,f19,f20] tsmetanaunorphaned : xcdroast [devel,f19,f20] pghmcfc unorphaned : perl-Mail-Mbox-MessageParser [EL-6] notting unorphaned : Maelstrom [devel,f19,f20] cicku unorphaned : dmenu [devel,f19] cicku unorphaned : i3status [devel,f19,f20] petersenunorphaned : ghc-smallcheck [f19,f20] filiperossetunorphaned : freeDiameter [EL-6,devel,f19,f20] filiperossetunorphaned : clive [devel,f19,f20] petersenunorphaned : ghc-type-level [f20] petersenunorphaned : ghc-ansi-terminal [EL-6,devel,f19,f20] petersenunorphaned : ghc-MonadCatchIO-mtl [devel,f19,f20] nonamedotc unorphaned : csmith [devel,f19,f20] lkundrakunorphaned : erlang-meck [epel7] cicku unorphaned : yapet [EL-5,EL-6,devel,f20] filiperossetunorphaned : sbackup [EL-6,devel] filiperossetunorphaned : python-myhdl [devel,f19] 4 packages were retired postgresql-plparrot [EL-6,devel,f19,f20] was retired by gerd A PostgreSQL procedural language for the Parrot virtual machine https://admin.fedoraproject.org/pkgdb/acls/name/postgresql-plparrot transifex [EL-5] was retired by lbazan A system for distributed translation submissions https://admin.fedoraproject.org/pkgdb/acls/name/transifex zanata-python-client [EL-5,EL-6,devel,f20] was retired by dchen zanata-python-client is a client that communicate with Zanata server. https://admin.fedoraproject.org/pkgdb/acls/name/zanata-python-client python-repoze-who-friendlyform [EL-6] was retired by spot Collection of repoze.who friendly form plugins https://admin.fedoraproject.org/pkgdb/acls/name/python-repoze-who-friendlyform 22 packages changed owner - limbgave to cicku : libdiscid [epel7] limbgave to mcpierce : perl-qpid [epel7] limbgave to pghmcfc: perl-Log-Any-Adapter [epel7] limbgave to cicku : perl-Data-MessagePack [epel7] limbgave to terjeros : python-futures [EL-6] limb
Re: Looking for co-maintainer to fix build issue on ARM (zorba package)
On Sun, 23 Feb 2014 11:06:47 +0100 Martin Gieseking martin.giesek...@uos.de wrote: Hi, finally, I found some time to update one of my bigger packages (zorba) to the latest release and to adapt it to build successfully on f21. However, the package (still) fails to build for armv7hl. The generated binary segfauls and therefore also prevents creating additional files during the build process: https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2245704 Since the ARM emulation is horribly slow on my computers, I can't actually use it to debug the issue in a reasonable timespan. Before I exclude armv7hl from the build process, it would be great if someone could have a look and is interested in maintaining zorba for this arch. The recent srpm can be found here: http://mgieseki.fedorapeople.org/review/zorba-3.0.0-1.fc20.src.rpm I'd suggest filing a bug on it and making it block the ARMTracker blocker. And/or you could also ping the fedora-arm list: https://lists.fedoraproject.org/mailman/listinfo/arm Folks there might have more thoughts... 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: Looking for co-maintainer to fix build issue on ARM (zorba package)
Am 24.02.2014 16:49, schrieb Kevin Fenzi: On Sun, 23 Feb 2014 11:06:47 +0100 Martin Gieseking martin.giesek...@uos.de wrote: Hi, finally, I found some time to update one of my bigger packages (zorba) to the latest release and to adapt it to build successfully on f21. However, the package (still) fails to build for armv7hl. The generated binary segfauls and therefore also prevents creating additional files during the build process: https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2245704 I'd suggest filing a bug on it and making it block the ARMTracker blocker. And/or you could also ping the fedora-arm list: https://lists.fedoraproject.org/mailman/listinfo/arm Thanks for your suggestion. I've filed an ARMTacker bug and am going to look for further feedback on the fedora-arm list. Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Help Wanted: Fedora.next schedule estimation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tl;dr: FESCo needs to know what is going to need extra time to deliver Fedora.next in the Fedora 21 cycle. Now that the Fedora.next product PRDs have been approved, the next phase is to plan our execution. First of all, this will mean planning out how to deliver Fedora 21. In order to accurately scope the Fedora 21 effort, FESCo needs input from the working groups and the community at large to identify the major efforts that we will need to account for during this cycle. We would like to operate under the expectation that we can deliver at least a first pass at all three of these Products in the Fedora 21 timeframe. In the previous round of discussion, we agreed that we would have a F21 release no sooner than August, to guarantee at least that amount of time for QA and Rel Eng projects. Now it's time to fill in the details and make the timeline specific. The goal here is for us to prepare a list of significant material changes to existing Fedora Project processes in order to deliver this first pass of Fedora.next products. (If you shouted Bingo! while reading that sentence, I don't blame you). To define this more clearly, we need to identify what portions of the Fedora community will need more time than usual to build out tooling or simply execute more manual steps in order to deliver on three products as opposed to our more traditional methods. We're not just looking for we will need moar testing time! here. We want specific information and ideally novel ways to minimize such additional efforts. For example, if someone told us that QA would have to spend three times as much effort to validate three Products, we would also want to hear statements about how much of that work is duplicated and theoretically automateable. Then we would also want to know how much additional time would be needed to do that automation in this cycle (thereby saving much more time in future cycles). FESCo is amenable to extending the Fedora 21 schedule (within reason) to simplify life in the future. As a non-exhaustive list of example things we expect will need attention and would like input (particularly time-estimates) on: * Quality Assurance: Coverage increases and automation such as Task-o-Tron[1] * Release Engineering: Re-tooling and automation. * Documentation Team: Impact on creating documentation for three products. * Ambassadors: How do we market these new products and do we need to account for time to deliver marketing materials? * Websites Team: What sort of redesign work will we need to go through? * Working Groups: How long to deliver new technologies? * Marketing: What to distribute to folks at conferences, how to convey fedora.next to our users. * Translators: Need to be kept in the loop on any new stuff added that requires translations. * Infrastructure: applications changes to meet fedora.next needs or new applications development to help do so. (bodhi changes, etc) * Design: consider logos and other needs of products and what it might take to make them happen. These are just a few examples. We expect there to be plenty of other cases that need to be addressed, which is why we would like to hear them as soon as possible. FESCo will be attempting to determine a Fedora 21 schedule in the near future and would prefer not to make this decision in ignorance. We do not have a formal process in place for organizing such planning efforts, but as a provisional one, we'd like to take the following steps: 1. Product working groups report on changes they want 2. Other groups also note similar changes they want to see 3. Discussion about what can realistically be done this time around with various stakeholders (including the list above) 4. Negotiation of how that will affect the product release plans for f21 5. FESCo will create and publish the schedule PRDs, Discussion Lists and Freenode IRC Channels: Fedora Cloud: https://fedoraproject.org/wiki/Cloud_PRD cl...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/cloud #fedora-cloud Fedora Server: https://fedoraproject.org/wiki/Server/Product_Requirements_Document ser...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server #fedora-server Fedora Workstation: https://fedoraproject.org/wiki/Workstation/Workstation_PRD desk...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/desktop #fedora-workstation [1] https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMLhRkACgkQeiVVYja6o6OkMgCeJ674UNPKoS542bfN8eGzErS/ EFgAnA4K4/nmGezRbhQFIqFNpBmGz56U =Bqdm -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2014-02-19)
On Feb 24, 2014 1:46 AM, Marcela Mašláňová mmasl...@redhat.com wrote: On 02/19/2014 08:57 PM, Tomas Mraz wrote: * Open floor (t8m, 19:45:44) * AGREED: FESCo expects the Tech specs/docs from working groups by March 3rd at the latest (+7, -0, 0:0) (t8m, 19:50:38) * ACTION: t8m will update the weekly reports ticket with this request (t8m, 19:53:08) Env and Stacks WG are dependent on requirements from 3 products, so we probably can't deliver on 3rd March. We can start though. For instance, we've decided that we're forging ahead with the idea of a repo for less than perfect packages. So we'll need the support infrastructure for that. - Disk space? - hooked up to the mirror network? - copr out of beta? - what scripts and manpower does the new repo need? - are we using bodhi, signing packages, etc? - do we need a set of people who check what goes into the new repo? -toshio -- 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: Java headless bugs
Slightly off-topic: fedora-review is telling packagers NOT to add Requires: jpackage-utils to javadoc subpackages because that is added automatically, but I see no mention of this on https://fedoraproject.org/wiki/Packaging:Java. Guidelines state that package must have R: jpackage-utils because it contains filesystem (/usr/share/javadoc directory). Where does it say that? I can see this bit: Java binary packages or their dependencies MUST have Requires (generated by RPM or manual) on: * java-headless or java-headless = 1:minimal_required_version * jpackage-utils but that doesn't seem to apply to -javadoc subpackages. If the requires is generated automatically all the better but that's not the guidelines scope IMO. It does seem to be generated automatically, so I followed fedora-review's advice at the weekend, and removed the jpackage-utils dependency from a few of my packages... Rich -- Richard Fearn richardfe...@gmail.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: Agenda for Env-and-Stacks WG meeting (2014-02-25)
On Mon, Feb 24, 2014 at 3:56 PM, Marcela Mašláňová mmasl...@redhat.com wrote:
WG meeting will be at 16:00 UTC in #fedora-meeting on Freenode.
== Topic ==
# additional repository
fedora-{incubator,ugly}
* better name than ugly based on content of repo
* github-like frontend for copr
* discuss policies/procedures for accepting copr repo
Just a note maybe how multilib is handled by those repos should be
discussed. coprs lack of multilib support is already causing problems
for people trying out the gnome 3.12 test repo.
We probably should use mash to compose them to make them really
compatible with how we do things in the main repo.
(Not sure I will be there for the meeting time so dropping the comment here).
--
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: Help Wanted: Fedora.next schedule estimation
On 24 February 2014 10:44, Stephen Gallagher sgall...@redhat.com wrote: As a non-exhaustive list of example things we expect will need attention and would like input (particularly time-estimates) on: * Quality Assurance: Coverage increases and automation such as Task-o-Tron[1] * Release Engineering: Re-tooling and automation. * Documentation Team: Impact on creating documentation for three products. * Ambassadors: How do we market these new products and do we need to account for time to deliver marketing materials? * Websites Team: What sort of redesign work will we need to go through? * Working Groups: How long to deliver new technologies? * Marketing: What to distribute to folks at conferences, how to convey fedora.next to our users. * Translators: Need to be kept in the loop on any new stuff added that requires translations. * Infrastructure: applications changes to meet fedora.next needs or new applications development to help do so. (bodhi changes, etc) * Design: consider logos and other needs of products and what it might take to make them happen. These are just a few examples. We expect there to be plenty of other cases that need to be addressed, which is why we would like to hear them as soon as possible. FESCo will be attempting to determine a Fedora 21 schedule in the near future and would prefer not to make this decision in ignorance. I am going to say that there are quite a few train problems here that can't be seen without the Next getting further defined. A possible infrastructure one would be: * Storage needs. Our combined supported release storage tries to be under 1TB and a lot of mirrors don't even copy all of that. How much extra disk space will all the images require. Images are less able to be deduplicated and can quickly push our storage over that. Storage for the amount of disk access needed on the mirrors is also expensive (300GB SAS drives versus 4TB SATA drives, etc.) Since we must also keep archives there needs to be additional storage there also over time. * Bandwidth needs. [Related to Storage.] The less mirrors have, the more the bandwidth gets pulled by the Red Hat network. There are limits to how much we can use here and changes to it usually occur after you need it. * Download changes.. this actually falls into infrastructure, design and webgroups. Where does start take you? Where does one get all the new images from? What other application changes are needed. All of these will probably have to fall into F22 because it will take F21 for the lower layers to cement. -- Stephen J Smoogen. -- 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: systeminfo - review package
Hi,
sorry that i am replying so late. I checked your suggestions, replaced
/usr/bin with
%{_bindir}. I also gave there 0%{?el5} shortcut
--
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: python-django update to Django-1.6
On 2014-02-21 10:55, Matthias Runge wrote: On Fri, Feb 21, 2014 at 01:28:54PM -0500, Stephen Gallagher wrote: On 02/21/2014 01:14 PM, Matthias Runge wrote: On Fri, Feb 21, 2014 at 10:36:24AM -0500, Simo Sorce wrote: +1 I still have an application that is slowly moving to 1.5 but not there yet and it is painful to have to keep an older Fedora Version running just because of that. I hear you! My current plan would be, to provide at least a python-django-1.5 version. My suggestion would actually be that Fedora releases should ship ONLY with the latest supported upstream version and should be allowed to pick up the next one during its supported lifecycle. Hmm, looking at larger Django applications included in Fedora. Askbot: still requires exclusively Django-1.4, does not work with later versions. I wouldn't block too hard on askbot in Fedora. We (me, nirik, and some other people I've forgotten) were looking at it recently - in the context of unbundling tinymce, or something - and it's basically DOA so far as Fedora goes. We strongly suspect the package hasn't worked on Fedora for years (or, possibly, ever). The current F20 and Rawhide packages at least certainly can't possibly really work (unless someone's fixed an awful lot of stuff in the last three weeks or so). The package exists to back ask.fedoraproject.org , basically (that, of course, runs on EL6). I doubt there's any other live askbot deployment using the Fedora/EPEL packages. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net 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
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the epel-7 tree: On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-Mail-Mbox-MessageParser ownership changed
Package perl-Mail-Mbox-MessageParser in Fedora EPEL 6 was orphaned by mmaslano To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Mail-Mbox-MessageParser -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-Mail-Mbox-MessageParser ownership changed
Package perl-Mail-Mbox-MessageParser in Fedora EPEL 5 was orphaned by mmaslano To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Mail-Mbox-MessageParser -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-Mail-Mbox-MessageParser ownership changed
Package perl-Mail-Mbox-MessageParser in Fedora EPEL 5 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Mail-Mbox-MessageParser -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-Mail-Mbox-MessageParser ownership changed
Package perl-Mail-Mbox-MessageParser in Fedora EPEL 6 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Mail-Mbox-MessageParser -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBD-ODBC] Fix formatting of Changes
commit 650b6075293bb84393eff4ac7137864c6dc0d14b Author: Jan Holcapek holca...@gmail.com Date: Mon Feb 24 11:42:52 2014 +0100 Fix formatting of Changes Changes.patch | 1294 perl-DBD-ODBC.spec |8 +- 2 files changed, 1301 insertions(+), 1 deletions(-) --- diff --git a/Changes.patch b/Changes.patch new file mode 100644 index 000..caeeb55 --- /dev/null +++ b/Changes.patch @@ -0,0 +1,1294 @@ +--- ./Changes 2014-02-24 11:29:10.083463035 +0100 ./Changes 2014-02-24 11:30:29.734483239 +0100 +@@ -3,9 +3,11 @@ + + =encoding utf8 + ++=head1 NAME ++ + DBD::ODBC::Changes - Log of significant changes to the DBD::ODBC + +-1.47 2014-02-19 ++=head2 1.47 2014-02-19 + + Full release of the 1.46 development releases. + +@@ -17,7 +19,7 @@ + NOTE the changes.cpanhq.com site does not yet support unknown for + dates. + +-1.46_2 2013-12-17 ++=head2 1.46_2 2013-12-17 + + [BUG FIXES] + +@@ -30,7 +32,7 @@ + + Added test 90_trace_flag.t + +-1.46_1 2013-11-16 ++=head2 1.46_1 2013-11-16 + + [CHANGE IN BEHAVIOUR] + +@@ -63,7 +65,7 @@ + + Added test 45_unicode_varchar.t for MS SQL Server only so far. + +-1.45 2013-10-28 ++=head2 1.45 2013-10-28 + + [CHANGE IN BEHAVIOUR] + +@@ -88,7 +90,7 @@ + Small changes to 20SqlServer.t test to skip some tests and note the + problem if SQLExecute returns SQL_NO_DATA on a non searched update. + +-1.44_4 2013-10-16 ++=head2 1.44_4 2013-10-16 + + [BUG FIXES] + +@@ -107,7 +109,7 @@ + Updates to the odbc_more_results pod to help clarify its use after + some confusion was seen in a perlmonks thread. + +-1.44_3 2013-10-11 ++=head2 1.44_3 2013-10-11 + + [CHANGE IN BEHAVIOUR] + +@@ -143,7 +145,7 @@ + SQLGetTypeInfo. It also issues a warning. See + http://www.postgresql.org/message-id/524ef455.6050...@ntlworld.com + +-1.44_3 2013-10-11 ++=head2 1.44_3 2013-10-11 + + [MISCELLANEOUS] + +@@ -152,7 +154,7 @@ + + Fixed some compiler warnings when attempting to print/trace SvCUR. + +-1.44_2 2013-09-07 ++=head2 1.44_2 2013-09-07 + + [BUG FIXES] + +@@ -180,7 +182,7 @@ + + Added 87_odbc_log_read.t test. + +-1.44_1 2013-06-06 ++=head2 1.44_1 2013-06-06 + + Moved from subversion to github as svn.perl.org is closing down. + Changed docs to show new repository. +@@ -194,7 +196,7 @@ + probably only see this if you are using fetchall_arrayref with a + slice and setting TYPE or attributes in bind_col first. + +-1.43 2013-03-06 ++=head2 1.43 2013-03-06 + + This is a full release of all the 1.42_* development releases. + +@@ -205,20 +207,20 @@ + Minor fix to 10handler.t test suite which relied on a native error + being true instead of defined. + +-1.42_5 2013-01-25 ++=head2 1.42_5 2013-01-25 + + [BUG FIXES] + + Not all modules used in test code were specified in build_requires. + +-1.42_4 2013-01-21 ++=head2 1.42_4 2013-01-21 + + [ENHANCEMENTS] + + odbc_trace and odbc_trace_file are now full connection attributes + so you can set them any time you like, not just in connect. + +-1.42_3 2013-01-17 ++=head2 1.42_3 2013-01-17 + + [ENHANCEMENTS] + +@@ -228,7 +230,7 @@ + only enable ODBC API tracing in the application which made the call + unlike the ODBC Driver Manager settings. + +-1.42_2 2012-12-17 ++=head2 1.42_2 2012-12-17 + + [MISCELLANEOUS] + +@@ -236,7 +238,7 @@ + from Dave Mitchell and posting at + http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2012-12/msg00424.html. + +-1.42_1 2012-12-12 ++=head2 1.42_1 2012-12-12 + + [BUG FIXES] + +@@ -265,7 +267,7 @@ + + New rt_81911.t test case. + +-1.42_0 2012-11-28 ++=head2 1.42_0 2012-11-28 + + [BUG FIXES] + +@@ -298,11 +300,11 @@ + + RT 80446 - fix spelling mistake - thanks to Xavier Guimar. + +-1.41 2012-10-23 ++=head2 1.41 2012-10-23 + + A full release of the 1.40 development release series. + +-1.40_3 2012-10-08 ++=head2 1.40_3 2012-10-08 + + [BUG FIXES] + +@@ -325,7 +327,7 @@ + + More documentation for odbc_out_connect_string. + +-1.40_2 2012-09-06 ++=head2 1.40_2 2012-09-06 + + [BUG FIXES] + +@@ -344,7 +346,7 @@ + + Added Test::NoWarnings to some tests where it was missing. + +-1.40_1 2012-09-04 ++=head2 1.40_1 2012-09-04 + + [BUG FIXES] + +@@ -370,7 +372,7 @@ + If you attempt to bind an rv without amagic DBD::ODBC will now + croak - related to rt 78838. + +-1.39 2012-07-07 ++=head2 1.39 2012-07-07 + + [BUG FIXES] + +@@ -380,7 +382,7 @@ + execute_for_fetch.pl example had not be changed since + odbc_disable_array_operations became odbc_array_operations. + +-1.38_3 2012-06-25 ++=head2 1.38_3 2012-06-25 + + [BUG FIXES] + +@@ -396,14 +398,14 @@ + + Made pod.t an author test. + +-1.38_2 2012-05-24 ++=head2 1.38_2 2012-05-24 + + [ENHANCEMENTS] + + Added support for Oracle TAF (assuming your ODBC driver supports it) + - see odbc_taf_callback. + +-1.38_1 2012-05-19 ++=head2 1.38_1 2012-05-19 + + [BUG
[perl-DBD-ODBC/f19] Fix formatting of Changes
Summary of changes: 650b607... Fix formatting of Changes (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBD-ODBC/f18] Fix formatting of Changes
Summary of changes: 650b607... Fix formatting of Changes (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBD-ODBC/f20] Fix formatting of Changes
Summary of changes: 650b607... Fix formatting of Changes (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBD-ODBC/el6] Fix formatting of Changes
Summary of changes: 650b607... Fix formatting of Changes (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Math-NumSeq-69.tar.gz uploaded to lookaside cache by churchyard
A file has been added to the lookaside cache for perl-Math-NumSeq: c5543cd98a432c779263de4ab7de548a Math-NumSeq-69.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Math-NumSeq] New version 69 (#1066371)
commit 2be0e02c7bb0b5ed03ab5ab2eeb0f5c94074dd09
Author: Miro Hrončok m...@hroncok.cz
Date: Mon Feb 24 12:25:38 2014 +0100
New version 69 (#1066371)
.gitignore|1 +
perl-Math-NumSeq.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 31fb659..f91cfd5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@
/Math-NumSeq-66.tar.gz
/Math-NumSeq-67.tar.gz
/Math-NumSeq-68.tar.gz
+/Math-NumSeq-69.tar.gz
diff --git a/perl-Math-NumSeq.spec b/perl-Math-NumSeq.spec
index 0a3072b..b96a1a1 100644
--- a/perl-Math-NumSeq.spec
+++ b/perl-Math-NumSeq.spec
@@ -1,5 +1,5 @@
Name: perl-Math-NumSeq
-Version:68
+Version:69
Release:1%{?dist}
Summary:Number sequences
License:GPLv3+
@@ -96,6 +96,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Feb 24 2014 Miro Hrončok mhron...@redhat.com - 69-1
+- New version 69 (#1066371)
+
* Thu Jan 30 2014 Miro Hrončok mhron...@redhat.com - 68-1
- New version 68 (#1059636)
diff --git a/sources b/sources
index f9a5835..7fdb1c7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0c93d5096d2b33dad25b560e052dffcd Math-NumSeq-68.tar.gz
+c5543cd98a432c779263de4ab7de548a Math-NumSeq-69.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBD-ODBC/epel7] (2 commits) ...Fix formatting of Changes
Summary of changes: 8b7289a... Updated to upstream version 1.47 (*) 650b607... Fix formatting of Changes (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1066371] perl-Math-NumSeq-69 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1066371 Miro Hrončok mhron...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2014-02-24 06:36:45 --- Comment #1 from Miro Hrončok mhron...@redhat.com --- http://koji.fedoraproject.org/koji/taskinfo?taskID=6564282 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Sh0UUaIaMaa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Build] Document Build's run-time dependencies
commit 016f1b17450070914b5b9ddd2c45b5628f91d669
Author: Petr Písař ppi...@redhat.com
Date: Mon Feb 24 13:22:30 2014 +0100
Document Build's run-time dependencies
perl-Module-Build.spec |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
---
diff --git a/perl-Module-Build.spec b/perl-Module-Build.spec
index f953267..cc26495 100644
--- a/perl-Module-Build.spec
+++ b/perl-Module-Build.spec
@@ -83,6 +83,13 @@ Requires: perl(Test::Harness)
Requires: perl(Pod::Html)
Requires: perl(Pod::Man) = 2.17
Requires: perl(Pod::Text)
+# Run-time for generated Build scripts from Build.PLs:
+# Those are already found by dependency generator. Just make sure they
+# present.
+# Cwd
+# File::Basename
+# File::Spec
+# strict
%{?perl_default_filter}
# Remove under-specified dependencies
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061604] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=1061604 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- stompclt-1.1-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=oZ4IXr7IwCa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1067185] perl-CGI-Application: information disclosure flaw [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1067185 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- Package perl-CGI-Application-4.50-7.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-CGI-Application-4.50-7.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-2998/perl-CGI-Application-4.50-7.fc19 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=hWjWbUtgnVa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1060465] Review Request: perl-Excel-Writer-XLSX - Create a new file in the Excel 2007+ XLSX format
https://bugzilla.redhat.com/show_bug.cgi?id=1060465 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Excel-Writer-XLSX-0.76 ||-1.fc19 Resolution|--- |ERRATA Last Closed|2014-02-12 05:11:02 |2014-02-24 07:29:55 --- Comment #20 from Fedora Update System upda...@fedoraproject.org --- perl-Excel-Writer-XLSX-0.76-1.fc19 has been pushed to the Fedora 19 stable repository. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kyidQ0VD1da=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1060465] Review Request: perl-Excel-Writer-XLSX - Create a new file in the Excel 2007+ XLSX format
https://bugzilla.redhat.com/show_bug.cgi?id=1060465 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Excel-Writer-XLSX-0.76 |perl-Excel-Writer-XLSX-0.76 |-1.fc19 |-1.fc20 --- Comment #21 from Fedora Update System upda...@fedoraproject.org --- perl-Excel-Writer-XLSX-0.76-1.fc20 has been pushed to the Fedora 20 stable repository. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=cRM3ptMPL6a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061604] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=1061604 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- stompclt-1.1-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=mPHaecmrYBa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1060360] Request branch
https://bugzilla.redhat.com/show_bug.cgi?id=1060360 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Assignee|mmasl...@redhat.com |nathan...@gnat.ca -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=TT75qbtt7Ma=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1068742] Request epel7 branch
https://bugzilla.redhat.com/show_bug.cgi?id=1068742 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Assignee|mmasl...@redhat.com |nathan...@gnat.ca -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=YPHg5lm6xja=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-DBD-ODBC
perl-DBD-ODBC has broken dependencies in the rawhide tree: On x86_64: perl-DBD-ODBC-1.47-1.fc21.x86_64 requires perl(the) On i386: perl-DBD-ODBC-1.47-1.fc21.i686 requires perl(the) On armhfp: perl-DBD-ODBC-1.47-1.fc21.armv7hl requires perl(the) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] portability issue: scripts expecting /bin/sh to be bash
Hi I noticed that some shell scripts have bashisms in them, on Debian and it's derivatives /bin/sh is dash. A quick list of scripts shipped by 389-ds-base having this issue: monitor ldif2db ldif2ldap db2bak vlvindex dn2rdn restoreconfig saveconfig upgradedb suffix2instance dbverify but since I just ran all the scripts without any options, there might be others too that fail with unexpected operator errors etc when ran in a real environment. So maybe change all of them to use /bin/bash or migrate them to be posix compatible (and somehow test new ones for compliance)? -- t -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review (take #2) ticket 47699: Propagate plugin precedence to all registered function types
https://fedorahosted.org/389/attachment/ticket/47699/0002-Ticket-ticket47699-Propagate-plugin-precedence-to-al.patch taking into account Rich and Mark reviews -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
Rich Megginson wrote: On 02/24/2014 09:00 AM, thierry bordaz wrote: Hello, IPA team filled this ticket https://fedorahosted.org/389/ticket/47553. It requires an ACI improvement so that during a MODDN a given user is only allowed to move an entry from one specified part of the DIT to an other specified part of the DIT. This without the need to grant the ADD permission. Here is the design of what could be implemented to support this need http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation regards thierry Since this not related to any Red Hat internal or customer information, we should move this discussion to the 389-devel list. Hi Thierry, Your design looks good. A minor question. The doc does not mention about deny. For instance, in your example DIT, can I allow moddn_to and moddn_from on the top dc=example,dc=com and deny them on cn=tests. Then, I can move an entry between cn=accounts and staging, but not to/from cn=tests? Or deny is not supposed to use there? Thanks, --noriko -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
On 02/24/2014 02:47 PM, Noriko Hosoi wrote: Rich Megginson wrote: On 02/24/2014 09:00 AM, thierry bordaz wrote: Hello, IPA team filled this ticket https://fedorahosted.org/389/ticket/47553. It requires an ACI improvement so that during a MODDN a given user is only allowed to move an entry from one specified part of the DIT to an other specified part of the DIT. This without the need to grant the ADD permission. Here is the design of what could be implemented to support this need http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation regards thierry Since this not related to any Red Hat internal or customer information, we should move this discussion to the 389-devel list. Hi Thierry, Your design looks good. A minor question. The doc does not mention about deny. For instance, in your example DIT, can I allow moddn_to and moddn_from on the top dc=example,dc=com and deny them on cn=tests. Then, I can move an entry between cn=accounts and staging, but not to/from cn=tests? Or deny is not supposed to use there? In which entry do you set these ACIs? Do you set aci: (target=ldap:///cn=staging,dc=example,dc=com;)(version 3.0; acl MODDN from; allow (moddn_from)) userdn=ldap:///uid=admin_accounts,dc=example,dc=com; ;) in the cn=accounts,dc=example,dc=com entry? Do you set aci: (target=ldap:///cn=accounts,dc=example,dc=com;)(version 3.0; acl MODDN to; allow (moddn_to)) userdn=ldap:///uid=admin_accounts,dc=example,dc=com; ;) in the cn=staging,dc=example,dc=com entry? Thanks, --noriko -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: test vs check naming consistency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/25/2014 06:10 AM, Tim Flink wrote: That being said, I'm not sure there is enough benefit to fight the common usage of the term unit testing. While they are checks by the definitions I listed above, the cost of re-defining all unit tests as unit checks would be rather high and I'm not convinced that there's enough benefit there to justify the attempt. Aye, this sounds like an attempt to redefine terms that are already in common use with a different meaning, and hence doomed to failure. Automated testing and acceptance testing are already different things, and the value of independent acceptance testing mostly lies in picking up this workflow doesn't make any sense and if I do X and Y at the same time, Z breaks kinds of usability and combinatorial errors that automated testing will blithely ignore (because it didn't occur to the developers to test it that way). Cheers, Nick. - -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTC/6VAAoJEHEkJo9fMO/Lp6IH/RZh8l60/vWDfHP17Yryyffi pe+2Zi8RLAhvald6KVRdb1MK0m6kUARVYvt8qpdkOXJcOIZgENw8dsqR3QVFxlXZ nJhEMEK1RwhhxrasYpD2s8VYNW+Ot7wzc5/JjIrxBKidlGkKICoGfG4ZOqxq4RW+ eYzGRw24foR6es5iRGLZi4COnXdPi3/3KAq3IijIbuCnxZUg+bCfhNRj1c+Bzq2E 0+38dh1xGdivBD3rKKwjcaBzp8TsUa6mWnSDq8LUrG+exn3uCxTu8wC1TMesx/Mg Uao1VjYggs56cEKfCQAn5g6GuScgcpFIoqQAlKZ5UrCu8zEeciJTTxk9yEdhIGQ= =P2LQ -END PGP SIGNATURE- ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Help Wanted: Fedora.next schedule estimation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tl;dr: FESCo needs to know what is going to need extra time to deliver Fedora.next in the Fedora 21 cycle. Now that the Fedora.next product PRDs have been approved, the next phase is to plan our execution. First of all, this will mean planning out how to deliver Fedora 21. In order to accurately scope the Fedora 21 effort, FESCo needs input from the working groups and the community at large to identify the major efforts that we will need to account for during this cycle. We would like to operate under the expectation that we can deliver at least a first pass at all three of these Products in the Fedora 21 timeframe. In the previous round of discussion, we agreed that we would have a F21 release no sooner than August, to guarantee at least that amount of time for QA and Rel Eng projects. Now it's time to fill in the details and make the timeline specific. The goal here is for us to prepare a list of significant material changes to existing Fedora Project processes in order to deliver this first pass of Fedora.next products. (If you shouted Bingo! while reading that sentence, I don't blame you). To define this more clearly, we need to identify what portions of the Fedora community will need more time than usual to build out tooling or simply execute more manual steps in order to deliver on three products as opposed to our more traditional methods. We're not just looking for we will need moar testing time! here. We want specific information and ideally novel ways to minimize such additional efforts. For example, if someone told us that QA would have to spend three times as much effort to validate three Products, we would also want to hear statements about how much of that work is duplicated and theoretically automateable. Then we would also want to know how much additional time would be needed to do that automation in this cycle (thereby saving much more time in future cycles). FESCo is amenable to extending the Fedora 21 schedule (within reason) to simplify life in the future. As a non-exhaustive list of example things we expect will need attention and would like input (particularly time-estimates) on: * Quality Assurance: Coverage increases and automation such as Task-o-Tron[1] * Release Engineering: Re-tooling and automation. * Documentation Team: Impact on creating documentation for three products. * Ambassadors: How do we market these new products and do we need to account for time to deliver marketing materials? * Websites Team: What sort of redesign work will we need to go through? * Working Groups: How long to deliver new technologies? * Marketing: What to distribute to folks at conferences, how to convey fedora.next to our users. * Translators: Need to be kept in the loop on any new stuff added that requires translations. * Infrastructure: applications changes to meet fedora.next needs or new applications development to help do so. (bodhi changes, etc) * Design: consider logos and other needs of products and what it might take to make them happen. These are just a few examples. We expect there to be plenty of other cases that need to be addressed, which is why we would like to hear them as soon as possible. FESCo will be attempting to determine a Fedora 21 schedule in the near future and would prefer not to make this decision in ignorance. We do not have a formal process in place for organizing such planning efforts, but as a provisional one, we'd like to take the following steps: 1. Product working groups report on changes they want 2. Other groups also note similar changes they want to see 3. Discussion about what can realistically be done this time around with various stakeholders (including the list above) 4. Negotiation of how that will affect the product release plans for f21 5. FESCo will create and publish the schedule PRDs, Discussion Lists and Freenode IRC Channels: Fedora Cloud: https://fedoraproject.org/wiki/Cloud_PRD cl...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/cloud #fedora-cloud Fedora Server: https://fedoraproject.org/wiki/Server/Product_Requirements_Document ser...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server #fedora-server Fedora Workstation: https://fedoraproject.org/wiki/Workstation/Workstation_PRD desk...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/desktop #fedora-workstation [1] https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMLhRkACgkQeiVVYja6o6OkMgCeJ674UNPKoS542bfN8eGzErS/ EFgAnA4K4/nmGezRbhQFIqFNpBmGz56U =Bqdm -END PGP SIGNATURE- ___ devel-announce mailing list devel-announce@lists.fedoraproject.org
