Re: New Fedora openid provider (fas-openid) in service
On 05/03/13 10:39 PM, Kurt Seifried wrote: can I use my existing openid? kurt.seifried.org http://kurt.seifried.org. That's not really a question that makes sense. Fedora runs an OpenID provider which gives you an OpenID associated with your 'Fedora identity' - ultimately, it's backed by your FAS account. Your own OpenID is a completely different identity. The idea of 'using' your 'existing' OpenID with Fedora's OpenID provider is just not an idea that is compatible with how OpenID works. -- 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
Re: Issue creating systemd service files
在 2013-3-6 PM3:33，Pierre-Yves Chibon pin...@pingoured.fr写道： On Wed, 2013-03-06 at 11:49 +0800, Christopher Meng wrote: Wrong list, please. How so? Pierre Weird, I didn't reply to this thread... Sorry... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Mon, Mar 04, 2013 at 07:18:04PM +0100, Miloslav Trmač wrote: This is a proposal of changes to the way future Fedora cycles should work and integrate changes. Some of the things we want to achieve: * Make rawhide to be reliably installable and usable by developers by coherently introducing changes. * Define the interfaces that applications can rely on (and by inference, the ones that they can't). * Ensure that functionality implemented in Fedora doesn't unintentionally regress, and provide a clear way to change or replace earlier implementations. To do this, we propose to specify three levels of stability we attempt. These are defined at the level of interfaces (e.g. specific library/command/file), not at the level of packages: 1: Long-term ABI for applications that we don't want to break without significant discussion. For now, this will include the stable kernel and libc ABIs 2: Base design: A set of functionality that was implemented and needs to be kept working in any composed tree, including rawhide; may include specific commands. Behavior that other parts of the distribution depends on. Functionality accepted for this tier by FESCo using the planning process, and some interfaces this functionality relies on. 3: Internal API: we'll do our best not to change it within a release lifetime; basically the existing Fedora compatibility and update rules. e.g. Python/Perl/Ruby X.Y version, most library interfaces, and major aspects of UI. We also propose to build up automated tests to verify the tier 1 and tier 2 functionality, and use those tests on newly-built packages to gate inclusion in rawhide. If this gate will avoid the frequent broken deps in rawhide, then I'm all for it. The current situation where any package can be pushed to rawhide at any time which breaks any deps, is what makes rawhide pretty much useless to me. Of course there are many other things that can go wrong besides, but if we could at least reliably install rawhide packages without needing to be an expert in fixing broken RPM deps, then we'd be heading in the right direction. 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
Re: Error dependencies
On Wed, 6 Mar 2013 13:55:05 +0800, Christopher Meng wrote: Error: Package: policycoreutils-newrole-2.1.14-16.fc19.i686 (rawhide) Requires: policycoreutils = 2.1.14-16.fc19 Installed: policycoreutils-2.1.14-17.fc19.i686 (@rawhide) policycoreutils = 2.1.14-17.fc19 Available: policycoreutils-2.1.14-16.fc19.i686 (rawhide) policycoreutils = 2.1.14-16.fc19 Show yum list policycoreutils\* please. The error sounds as if you've switched between an up-to-date Rawhide mirror and an older one. The 2.1.14-17.fc19 build of the policycoreutils package set contains a corresponding -newrole subpackage: http://koji.fedoraproject.org/koji/buildinfo?buildID=399882 -- Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc0.git15.1.fc19.x86_64 loadavg: 0.88 0.75 0.45 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On 5 March 2013 17:52, Kevin Fenzi ke...@scrye.com wrote: On Tue, 05 Mar 2013 12:44:39 -0500 Stephen Gallagher sgall...@redhat.com wrote: This is local testing that has been done in concert with the feature to add enterprise login support to Anaconda/firstboot. There's currently no way to actually install from Rawhide cleanly in order to do that testing. Bummer. ;( There was a plan to do weekly install composes, but it was blocked by mock in rawhide being broken for a while. I am not sure what the hold up is now. Just to follow this up, F19 composes are occurring (I've just tried to check the latest on koji, but it seems to be busy). It seems Anaconda is broken in them, Brian Monroe reported this trying out the latest Fedora Jam compose on the music list: I'm getting this traceback on the most recent nightly iso when I try to install to Hard Drive. File /sbin/anaconda, line 719, in module from pyanaconda import kickstart File /usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py, line 760, in module class Network(commands.network.F19_Network): AttributeError: 'module' object has no attribute 'F19_Network -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [emelfm2] remove vendor tag from desktop file. https://fedorahosted.org/fpc/ticket/247
On Tue, 5 Mar 2013 06:10:20 -0500, Rahul Sundaram wrote: [...] but it appears that any change including dropping very old obsoletes is considered controversial or needless change or personal preference now and frankly, it is just less work for me to not care about other packages much. I find it sad that this is your point of view. It has left me pretty much speechless for a day. And rest assured, dropping very old obsoletes isn't controversial in general. That's my opinion. What's controversial is how to do it. It ought not be done with just a clean up spec to follow current guidelines entry. Point at a commit where you've dropped Obsoletes, and one could take a look. It would be a good habit to document dropped Obsoletes in a %changelog comment, for example. Provenpackagers ought to know that maintaining the %changelog properly is a good thing. You want to document what you've dropped and when you've dropped it, regardless of whether you considered it very old or straight-forward. In the same way, removing desktop vendor prefixes should be done right. When I contacted you about your changes last week, you refused to do it right and you responded that you think the upstream project is not active enough. Becoming co-maintainer for all of them just doesn't scale and I have more than enough in my plate already. I can just ride through even more obvious changes and be done with it or just not participate. Same here. :-/ That's an amazingly disappointing response from you. The whole motivation behind getting rid of the old desktop vendor prefix cruft is to get a chance to apply random clean-up in lots of packages? All or nothing? Such as dropping an excluded %doc file and its comment. Imagine that! Why would you drop lines a different packager has added deliberately? You've told me that some of your changes are scripted. Actually, you sort of re-review the packages you touch and change things you don't like or where you think you know better than the package maintainer(s). That's not okay. It doesn't work that way, because you cannot check every minor detail on wether another packager has added it back just recently. You admit that you've made some actual mistakes, but instead of being willing to compromise, a message later you want to stop all your activity. Wow! -- Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc0.git15.1.fc19.x86_64 loadavg: 0.27 0.39 0.38 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL [was Re: Should MariaDB touch my.cnf in %post?]
On 5. 3. 2013 at 19:14:25, Honza Horak wrote: On 03/05/2013 11:07 AM, Norvald H. Ryeng wrote: On Thu, 14 Feb 2013 16:17:00 +0100, Tom Lane t...@redhat.com wrote: The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named MySQL, MySQL-server, etc, which simply conflicted with the Red Hat-supplied packages named mysql, mysql-server, etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named MySQL, instead of figuring out how to transition maintainership of the mysql packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the mysql package name continues in use. I think we're going to have to end up with a design in which mysql becomes essentially a virtual Provides name. We now have a set of working 5.6.10 packages. The packages pass mtr tests and we've tested some of the packages that depend on MySQL (php, perl-DBD-MySQL, etc.). It all seems to be working well, so I think we're ready to get it into rawhide. I believe Bjørn Munch has already contacted you about how to upload, etc. I'm glad to hear that things get move on with MySQL-5.6 effort. We've kept the existing package names. I don't understand the reasons behind the name change you suggest. Honza Horák has added a real-mysql virtual provides, and this is provided by the existing mysql and mariadb packages, so it seems the infrastructure you suggest is already in place. Our 5.6.10 packages are just an upgrade of the existing mysql packages, so I see no need for a name change, and a change now would break upgrades for users that already have the mysql packages installed. We're still going to make mariadb the default in F19 as proposed in the Feature page. Since depended packages are now built against libmysqlclient.so from mariadb, we should really ensure mariadb package will be installed (if not explicitly requested otherwise by users), because MySQL lacks some client side features that mariadb adds -- so keeping MySQL installed would introduce potential compatibility problems. About the issues with the current way how the things are handling -- we introduced real-mysql virtual provides to distinguish between mysql package and mysql virtual name -- that doesn't work well in all aspects, it is not very clean and it also brings ambiguities. We decided to solve that as proposed above -- to introduce a new package MySQL (dist-git already done) where original MySQL project will be kept and eventually upgraded to 5.6 by contributors from Oracle. Package mysql will be retired as of F19 and the name mysql will exist only as a virtual provide for compatibility reasons. mariadb will provide mysql names, while MySQL won't -- ideally both packages could provide it but RPM cannot define a priority for preferring one of two packages that provide the same symbol. Is that right, Jan or Ales? Or anything changed in that field? Nothing has changed in this area - there are some heuristics used, I think the most used one is to pick the package with the shortest name ;-) I'm now pushing for proper support of versioning in provides, that might help you. But even if we decide to support it, we are still looking on a time frame of at least a month or so. So, the current plan with a new MySQL package will result in much more cleaner solution and should avoid ambiguities. Regards, Honza Note: In case there are some reactions, I'd like to excuse myself that I'll be off-line for a few days now and won't be able to respond until Monday. signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Wed, 06 Mar 2013 12:45:12 +0700, Michel Alexandre Salim wrote: On 05/03/13 01:20, Bill Nottingham wrote: Package emacs-rpm-spec-mode (orphan) That's a curious package, it lasted a few months, was never branched, and then is gone. And rpm-spec-mode.el has been provided by emacs-common for as long as I could remember. Doesn't seem to be the case: $ rpm -qla emacs\*|grep rpm /etc/rpm/macros.emacs /usr/share/emacs/24.2/lisp/pcmpl-rpm.elc Only with emacs-rpm-spec-mode I get macros such as rpm-add-changelog-entry and the real RPM SPEC whereas default Emacs without it only recognizes rpms as shell scripts[rpm]. Would be good if emacs-rpm-spec-mode could be kept. -- Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc0.git15.1.fc19.x86_64 loadavg: 0.09 0.05 0.11 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
On 03/04/2013 07:05 PM, Lennart Poettering wrote: On Mon, 04.03.13 10:24, David Highley (dhigh...@highley-recommended.com) wrote: Lennart Poettering wrote: On Mon, 04.03.13 07:56, David Highley (dhigh...@highley-recommended.com) wrote: Twice now we have one Fedora 18 system where systemd seems to get into a non responsive state. We are not able to get the status of any service and we're not able to do an init 6 to restart the system. Did notice today that a full process list showed a message about abrt and something to the effect nobody cared. We also see a number of defunct processes that seem to never clear. So far the only remedy we have found is a hard power cycle. Can you get a stack trace of PID1? sudo pstack 1 should already give a hint, but even better would be a a bt full via gdb. We are offsite right now so will dig deeper later. We had checked the log files and noticed that it complains about rsyncd not being able to connect to a port and there was another complaint about Gnome. The rsync one repeats as there are back ups that are not being serviced which is is what alerted to something being wrong. We are sending and receiving email from this system. It also has an internal web, mysql, and other subsystems which seem to work fine. So when this state occurs it sometimes takes a while to notice. This is a bug in libselinux: https://bugzilla.redhat.com/show_bug.cgi?id=901812 This is exact reason you don't make the most important user space program dependent on a lot of other stuff! Lennart -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OK to bump soname for a lesser-used library?
Dan Horák d...@danny.cz writes: Josh Stone píše v Út 05. 03. 2013 v 09:44 -0800: Is that feasible for C++ APIs? I mean, it might be possible if you're *really* careful about hiding class changes, but this project is not structured that way. it is, see eg. the wxWidgets library, they are really good in that Regarding C++ ABI, I found this worth reading: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130305 changes
Fedora Rawhide Report píše v Út 05. 03. 2013 v 14:07 +: [libgda] 1:libgda-tools-5.1.1-4.fc19.x86_64 requires libgraph.so.5()(64bit) tracked as FTBFS in https://bugzilla.redhat.com/show_bug.cgi?id=914131 - caused by a change in graphviz Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
On Wed, 06.03.13 06:55, Steve Clark (scl...@netwolves.com) wrote: On 03/04/2013 07:05 PM, Lennart Poettering wrote: On Mon, 04.03.13 10:24, David Highley (dhigh...@highley-recommended.com) wrote: Lennart Poettering wrote: On Mon, 04.03.13 07:56, David Highley (dhigh...@highley-recommended.com) wrote: Twice now we have one Fedora 18 system where systemd seems to get into a non responsive state. We are not able to get the status of any service and we're not able to do an init 6 to restart the system. Did notice today that a full process list showed a message about abrt and something to the effect nobody cared. We also see a number of defunct processes that seem to never clear. So far the only remedy we have found is a hard power cycle. Can you get a stack trace of PID1? sudo pstack 1 should already give a hint, but even better would be a a bt full via gdb. We are offsite right now so will dig deeper later. We had checked the log files and noticed that it complains about rsyncd not being able to connect to a port and there was another complaint about Gnome. The rsync one repeats as there are back ups that are not being serviced which is is what alerted to something being wrong. We are sending and receiving email from this system. It also has an internal web, mysql, and other subsystems which seem to work fine. So when this state occurs it sometimes takes a while to notice. This is a bug in libselinux: https://bugzilla.redhat.com/show_bug.cgi?id=901812 This is exact reason you don't make the most important user space program dependent on a lot of other stuff! True thing. libselinux is a library we really really should avoid linking against. I mean, it's almost as bad as libc, we really should avoid linking against that from PID 1 too. Oh man, those systemd guys are such idiots that they dare to link against libc and libselinux! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/13 18:32, Michael Schwendt wrote: On Wed, 06 Mar 2013 12:45:12 +0700, Michel Alexandre Salim wrote: On 05/03/13 01:20, Bill Nottingham wrote: Package emacs-rpm-spec-mode (orphan) That's a curious package, it lasted a few months, was never branched, and then is gone. And rpm-spec-mode.el has been provided by emacs-common for as long as I could remember. Doesn't seem to be the case: $ rpm -qla emacs\*|grep rpm /etc/rpm/macros.emacs /usr/share/emacs/24.2/lisp/pcmpl-rpm.elc Only with emacs-rpm-spec-mode I get macros such as rpm-add-changelog-entry and the real RPM SPEC whereas default Emacs without it only recognizes rpms as shell scripts[rpm]. Would be good if emacs-rpm-spec-mode could be kept. ✗ rpm -qf /usr/share/emacs/site-lisp/rpm-spec-mode.el emacs-common-24.2-6.fc18.x86_64 ✗ rpm -qla emacs\* | grep rpm /etc/rpm/macros.emacs /usr/share/emacs/24.2/lisp/pcmpl-rpm.elc /usr/share/emacs/site-lisp/rpm-spec-mode.el /usr/share/emacs/site-lisp/rpm-spec-mode.elc /usr/share/emacs/site-lisp/site-start.d/rpm-spec-mode-init.el Ah, I see, it's still there in Emacs 24.2 but no longer in the version of Emacs in Rawhide. Explaining why it showed up around the time F18 was branched from Rawhide (Sep 14). Taking it over. - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRNzXlAAoJEEr1VKujapN6rA4H/RPdGRy+9drP6zVAZnXN8bIq ty0fh8yfR/8DXi1xrw1icnHEd07T8VNZf4AKVwurPkkbezw82izf/KNG/A0kI/mS Lhm1crSeyPU8YvPeAgZM7QrSHu2hJ4mpPg6lzS6+P2F/dYYu/XbdmXApPZpd0iAq fSvp9KAhN0pLq4YsJIuyzRfkwdJSY/lbSVO42kIcUVkF/i1cKICliM7MlmaNrWaf TkWZuvjDFMt8kkn3fDpqDCzW9wQV57Tj2fwBWSFeygdXLb0f1I2tw7tWG+tTMub3 8zZ0TQxZj86F8am6p6LFgb8D1pWuwAgck6kbhdCZs88eTRnDS8Fk+bGvn193k5k= =tsZc -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Mon, Mar 4, 2013 at 10:20 AM, Bill Nottingham nott...@redhat.com wrote: Before we branch for Fedora 19, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 17. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 19. That is currently scheduled to happen on or around March 12. Package HippoDraw (orphan) Package PyPE (orphan) Package Temperature.app (orphan) Package afraid-dyndns (orphan) Package alsamixer-dockapp (orphan) Package aplus-fsf (fails to build) Package aswvdial (orphan) Package auto-nng (orphan) Package bamf (orphan) comaintained by: jspaleta Package blazeblogger (orphan) Package bouncycastle-tsp (orphan) Package bzr-explorer (orphan) Package c2050 (orphan) Package c2070 (orphan) Package canto (orphan) Package certmaster (orphan) comaintained by: alikins Package compton (orphan) Package cputnik (orphan) Package dasher (orphan) Package eclipse-m2m-qvtoml (fails to build) Package eclipse-mercurial (fails to build) comaintained by: overholt Package em8300 (orphan) Package emacs-ecb (orphan) Package emacs-rpm-spec-mode (orphan) Package emacs-slime (orphan) Package email2trac (fails to build) Package fcron (orphan) Package ganymed-ssh2 (orphan) comaintained by: akurtakov Package gkrellm-weather (orphan) Package global (orphan) Package gmyth (orphan) Package gnome-mag (orphan) Package griffith (orphan) Package gtksourceview2-sharp (fails to build) Package guimup (orphan) Package haildb (orphan) Package inamik-tableformatter (orphan) Package javacsv (orphan) Package jopt-simple (orphan) Package libdrizzle (orphan) Package libgnomecups (orphan) Package libindicator (orphan) comaintained by: jspaleta Package libopensync-plugin-sunbird (orphan) comaintained by: awjb Package lx (orphan) Package mimetic (orphan) Package mingw-openjpeg (orphan) comaintained by: epienbro Package mlmmj (orphan) Package mtpfs (orphan) Package nagios-plugins-rhev (fails to build) Package ncpfs (orphan) Package nitrogen (orphan) Package notification-daemon (orphan) Package obapps (orphan) Package ocaml-cmigrep (orphan) Package pbm2l2030 (orphan) Package pbm2l7k (orphan) Package pclock (orphan) Package perl-Bio-Graphics (orphan) comaintained by: alexlan Package perl-Fedora-Bugzilla (orphan) comaintained by: mmaslano Package perl-bioperl (orphan) comaintained by: alexlan Package perl-bioperl-run (orphan) comaintained by: alexlan Package pidgin-gfire (orphan) Package polkit-gnome (orphan) Package python-GeoIP (orphan) Package python-chm (orphan) Package python-drizzle (orphan) Package python-wsgi-jsonrpc (orphan) Package rubygem-acts-as-list (orphan) Package spicebird (orphan) Package sympy (orphan) Package trac-agilo-plugin (orphan) comaintained by: kevin Package util-vserver (orphan) Package vdr-skins (orphan) Package vdr-text2skin (orphan) Package vdr-wapd (orphan) Package volpack (orphan) Package wmSun (orphan) Package wmbinclock (orphan) Package wmblob (orphan) Package wmcalc (orphan) Package wmcore (orphan) Package wmcube (orphan) Package wmdrawer (orphan) Package wmeyes (orphan) Package wmnet (orphan) Package wmpuzzle (orphan) Package wmsystemtray (orphan) Package wmtictactoe (orphan) Package wmtop (orphan) Package wmwave (orphan) Package wmweather (orphan) Package xml-writer (orphan) List of deps left behind by packages which are orphaned or fail to build: Removing: bamf bamf-qt requires bamf-devel = 0.2.104-4.fc18 gnome-pie requires libbamf3.so.0 gnome-pie requires bamf3-devel = 0.2.104-4.fc18 Removing: bouncycastle-tsp itext requires bouncycastle-tsp = 1.46-6.fc19 itext-core requires bouncycastle-tsp = 1.46-6.fc19 Removing: c2050 printer-filters requires c2050 = 0.3b-7.fc19 Removing: c2070 printer-filters requires c2070 = 0.99-10.fc19 Removing: certmaster func requires certmaster = 0.28-5.fc19 Removing: gmyth gstreamer-plugins-bad-free requires gmyth-devel = 0.7.1-20.fc19 gstreamer-plugins-bad-free-extras requires libgmyth.so.0 Removing: jopt-simple springframework requires jopt-simple = 3.3-8.fc19 Removing: libgnomecups libgnomeprint22 requires libgnomecups-1.0.so.1 libgnomeprint22 requires libgnomecups-devel = 0.2.3-12.fc18 Removing: lx printer-filters requires lx = 20030328-9.fc19 Removing: ncpfs medusa requires libncp.so.2.3 medusa requires ncpfs-devel = 2.2.6-18.fc19 medusa requires libncp.so.2.3(NCPFS.2.2.0.17) medusa requires libncp.so.2.3(NCPFS_2.2.0.19) medusa requires libncp.so.2.3(NCPFS_2.2.1) Removing: notification-daemon gnome-session requires
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Wed, Mar 6, 2013 at 4:36 AM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, Mar 4, 2013 at 10:20 AM, Bill Nottingham nott...@redhat.com wrote: Before we branch for Fedora 19, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 17. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 19. That is currently scheduled to happen on or around March 12. Package HippoDraw (orphan) Package PyPE (orphan) Package Temperature.app (orphan) Package afraid-dyndns (orphan) Package alsamixer-dockapp (orphan) Package aplus-fsf (fails to build) Package aswvdial (orphan) Package auto-nng (orphan) Package bamf (orphan) comaintained by: jspaleta Package blazeblogger (orphan) Package bouncycastle-tsp (orphan) Package bzr-explorer (orphan) Package c2050 (orphan) Package c2070 (orphan) Package canto (orphan) Package certmaster (orphan) comaintained by: alikins Package compton (orphan) Package cputnik (orphan) Package dasher (orphan) Package eclipse-m2m-qvtoml (fails to build) Package eclipse-mercurial (fails to build) comaintained by: overholt Package em8300 (orphan) Package emacs-ecb (orphan) Package emacs-rpm-spec-mode (orphan) Package emacs-slime (orphan) Package email2trac (fails to build) Package fcron (orphan) Package ganymed-ssh2 (orphan) comaintained by: akurtakov Package gkrellm-weather (orphan) Package global (orphan) Package gmyth (orphan) Package gnome-mag (orphan) Package griffith (orphan) Package gtksourceview2-sharp (fails to build) Package guimup (orphan) Package haildb (orphan) Package inamik-tableformatter (orphan) Package javacsv (orphan) Package jopt-simple (orphan) Package libdrizzle (orphan) Package libgnomecups (orphan) Package libindicator (orphan) comaintained by: jspaleta Package libopensync-plugin-sunbird (orphan) comaintained by: awjb Package lx (orphan) Package mimetic (orphan) Package mingw-openjpeg (orphan) comaintained by: epienbro Package mlmmj (orphan) Package mtpfs (orphan) Package nagios-plugins-rhev (fails to build) Package ncpfs (orphan) Package nitrogen (orphan) Package notification-daemon (orphan) Package obapps (orphan) Package ocaml-cmigrep (orphan) Package pbm2l2030 (orphan) Package pbm2l7k (orphan) Package pclock (orphan) Package perl-Bio-Graphics (orphan) comaintained by: alexlan Package perl-Fedora-Bugzilla (orphan) comaintained by: mmaslano Package perl-bioperl (orphan) comaintained by: alexlan Package perl-bioperl-run (orphan) comaintained by: alexlan Package pidgin-gfire (orphan) Package polkit-gnome (orphan) Package python-GeoIP (orphan) Package python-chm (orphan) Package python-drizzle (orphan) Package python-wsgi-jsonrpc (orphan) Package rubygem-acts-as-list (orphan) Package spicebird (orphan) Package sympy (orphan) Package trac-agilo-plugin (orphan) comaintained by: kevin Package util-vserver (orphan) Package vdr-skins (orphan) Package vdr-text2skin (orphan) Package vdr-wapd (orphan) Package volpack (orphan) Package wmSun (orphan) Package wmbinclock (orphan) Package wmblob (orphan) Package wmcalc (orphan) Package wmcore (orphan) Package wmcube (orphan) Package wmdrawer (orphan) Package wmeyes (orphan) Package wmnet (orphan) Package wmpuzzle (orphan) Package wmsystemtray (orphan) Package wmtictactoe (orphan) Package wmtop (orphan) Package wmwave (orphan) Package wmweather (orphan) Package xml-writer (orphan) List of deps left behind by packages which are orphaned or fail to build: Removing: bamf bamf-qt requires bamf-devel = 0.2.104-4.fc18 gnome-pie requires libbamf3.so.0 gnome-pie requires bamf3-devel = 0.2.104-4.fc18 Removing: bouncycastle-tsp itext requires bouncycastle-tsp = 1.46-6.fc19 itext-core requires bouncycastle-tsp = 1.46-6.fc19 Removing: c2050 printer-filters requires c2050 = 0.3b-7.fc19 Removing: c2070 printer-filters requires c2070 = 0.99-10.fc19 Removing: certmaster func requires certmaster = 0.28-5.fc19 Removing: gmyth gstreamer-plugins-bad-free requires gmyth-devel = 0.7.1-20.fc19 gstreamer-plugins-bad-free-extras requires libgmyth.so.0 Removing: jopt-simple springframework requires jopt-simple = 3.3-8.fc19 Removing: libgnomecups libgnomeprint22 requires libgnomecups-1.0.so.1 libgnomeprint22 requires libgnomecups-devel = 0.2.3-12.fc18 Removing: lx printer-filters requires lx = 20030328-9.fc19 Removing: ncpfs medusa requires libncp.so.2.3 medusa requires ncpfs-devel = 2.2.6-18.fc19 medusa requires libncp.so.2.3(NCPFS.2.2.0.17) medusa requires libncp.so.2.3(NCPFS_2.2.0.19) medusa requires libncp.so.2.3(NCPFS_2.2.1)
Re: RFC: Fedora revamp proposal
- Original Message - On Tue, 5 Mar 2013 03:48:29 -0500 (EST) From tooling perspective - that's the question if we want to enhance our tools, step into other similar project (for collaboration with our downstreams? other distros...). yeah, I don't know. Perhaps someone could ask around and see if there's any projects/setups inside Red Hat that would be good for this? ABI checking and perhaps rpm diffing? I'm trying to ask guys around, what do they have and what they could offer for us. And sell it as a good thing for both sides ;-) Also, do any of the folks working on AutoQA think it could be used for this? Or would they suggest a different framework? I think we should definitely start small here and slowly work forward. Every single step in this direction would be great, I agree. The hardest part will be getting the initial tooling in place. Yep. (All this is assuming that this is a good idea that people want I guess). ;) Well, we have to do something - I expect we know it - now the question is how far do we want to go ;-) Jaroslav kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 and new version of Gnome (3.7.x)
On Tue, Mar 05, 2013 at 08:27:50PM +0800, Christopher Meng wrote: I don't suggest you doing that. Upgrading to Fedora 19 is not good for end users. That's rather negative. We want to encourage testers. I would suggest to the original poster: (1) Create a Fedora 18 virtual machine. (2) In the VM, do: yum install fedora-release-rawhide (3) Edit (in the VM) /etc/yum.repos.d/fedora-rawhide.repo and change enabled=0 to enabled=1 in the first section. (4) In the VM: yum update (5) Reboot the VM. (6) Connect to the VM with virt-viewer and run virt-viewer full screen. With any luck you'll now be testing GNOME whatever in Fedora 19! Remember to file bugs. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
On 03/06/2013 07:08 AM, Lennart Poettering wrote: On Wed, 06.03.13 06:55, Steve Clark (scl...@netwolves.com) wrote: On 03/04/2013 07:05 PM, Lennart Poettering wrote: On Mon, 04.03.13 10:24, David Highley (dhigh...@highley-recommended.com) wrote: Lennart Poettering wrote: On Mon, 04.03.13 07:56, David Highley (dhigh...@highley-recommended.com) wrote: Twice now we have one Fedora 18 system where systemd seems to get into a non responsive state. We are not able to get the status of any service and we're not able to do an init 6 to restart the system. Did notice today that a full process list showed a message about abrt and something to the effect nobody cared. We also see a number of defunct processes that seem to never clear. So far the only remedy we have found is a hard power cycle. Can you get a stack trace of PID1? sudo pstack 1 should already give a hint, but even better would be a a bt full via gdb. We are offsite right now so will dig deeper later. We had checked the log files and noticed that it complains about rsyncd not being able to connect to a port and there was another complaint about Gnome. The rsync one repeats as there are back ups that are not being serviced which is is what alerted to something being wrong. We are sending and receiving email from this system. It also has an internal web, mysql, and other subsystems which seem to work fine. So when this state occurs it sometimes takes a while to notice. This is a bug in libselinux: https://bugzilla.redhat.com/show_bug.cgi?id=901812 This is exact reason you don't make the most important user space program dependent on a lot of other stuff! True thing. libselinux is a library we really really should avoid linking against. I mean, it's almost as bad as libc, we really should avoid linking against that from PID 1 too. Oh man, those systemd guys are such idiots that they dare to link against libc and libselinux! Lennart Well you can be as sarcastic as you want but I have been using UNIX/Linux since 1985 and never had init hang or die on me. -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issue creating systemd service files
On Tue, 05.03.13 19:48, David Highley (dhigh...@highley-recommended.com) wrote: [Unit] Description=sshdfilter Daemon Documentation=file://usr/share/doc/sshdfilter-1.5.7/INSTALL.Fedora DefaultDependencies=no DefaultDependencies=no is unlikely what you want here. That's an option for early-boot stuff, not for normal services. [Service] Type=forking PIDFile=/var/run/sshdfilter.SSHD.pid ExecStart=/sbin/sshdfilter NotifyAccess=all This only makes sense if your daemon use sd_notify() from its C code. Does it really? [Install] WantedBy=multi-user.target sshdfilter.socket === [Unit] Description=sshdfilter Named Pipe Documentation=file:///usr/share/doc/sshdfilter-1.5.7/INSTALL.Fedora DefaultDependencies=no Same as above. After=syslog.target Redundant, it's implied. [Socket] ListenFIFO=/var/run/sshdfilter.fifo SocketMode=0644 This suggests your service is actually socket-activatable via this FIFO. Is it really? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
eigen3 license change
Hi all, I have updated the eigen3 package[1] to release 3.1.2 in rawhide. This update comes with a license change: eigen3 is now licensed as MPLv2.0 with parts licensed as LGPLv2+ and BSD. Affected packages include: fawkes (GPLv2+ and GPLv2+ with exceptions) [Pulled into via a development metapackage, not actually built into fawkes] mrpt (GPLv3+) pcl (BSD) sympol (GPLv2+) I will handle rebuilding mrpt, pcl, and fawkes (once this graphviz bug[2] is resolved). Rich [1] http://eigen.tuxfamily.org/index.php?title=Main_Page [2] https://bugzilla.redhat.com/show_bug.cgi?id=904790 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
On Tue, 05 Mar 2013 19:14:25 +0100, Honza Horak hho...@redhat.com wrote: On 03/05/2013 11:07 AM, Norvald H. Ryeng wrote: On Thu, 14 Feb 2013 16:17:00 +0100, Tom Lane t...@redhat.com wrote: The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named MySQL, MySQL-server, etc, which simply conflicted with the Red Hat-supplied packages named mysql, mysql-server, etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named MySQL, instead of figuring out how to transition maintainership of the mysql packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the mysql package name continues in use. I think we're going to have to end up with a design in which mysql becomes essentially a virtual Provides name. We now have a set of working 5.6.10 packages. The packages pass mtr tests and we've tested some of the packages that depend on MySQL (php, perl-DBD-MySQL, etc.). It all seems to be working well, so I think we're ready to get it into rawhide. I believe Bjørn Munch has already contacted you about how to upload, etc. I'm glad to hear that things get move on with MySQL-5.6 effort. We've kept the existing package names. I don't understand the reasons behind the name change you suggest. Honza Horák has added a real-mysql virtual provides, and this is provided by the existing mysql and mariadb packages, so it seems the infrastructure you suggest is already in place. Our 5.6.10 packages are just an upgrade of the existing mysql packages, so I see no need for a name change, and a change now would break upgrades for users that already have the mysql packages installed. We're still going to make mariadb the default in F19 as proposed in the Feature page. Since depended packages are now built against libmysqlclient.so from mariadb, we should really ensure mariadb package will be installed (if not explicitly requested otherwise by users), because MySQL lacks some client side features that mariadb adds -- so keeping MySQL installed would introduce potential compatibility problems. About the issues with the current way how the things are handling -- we introduced real-mysql virtual provides to distinguish between mysql package and mysql virtual name -- that doesn't work well in all aspects, it is not very clean and it also brings ambiguities. We decided to solve that as proposed above -- to introduce a new package MySQL (dist-git already done) where original MySQL project will be kept and eventually upgraded to 5.6 by contributors from Oracle. Package mysql will be retired as of F19 and the name mysql will exist only as a virtual provide for compatibility reasons. mariadb will provide mysql names, while MySQL won't -- ideally both packages could provide it but RPM cannot define a priority for preferring one of two packages that provide the same symbol. Is that right, Jan or Ales? Or anything changed in that field? In practice, this means that it will be almost impossible to install MySQL in Fedora. The recipe in the feature page [1] requires the user to 1. edit yum.conf to set excludes=mariadb* and obsoletes=0, 2. run yum shell to replace the packages, and 3. edit yum.conf again to remove obsoletes=0. This is not very user friendly. One thing is that the user would have to jump through all these hoops just to install a single package, but they also have to find this recipe in the first place. I fear this is the same as telling users no, you can't get MySQL. If the MySQL packages don't provide mysql*, how can they fulfill dependencies? Everything that depends on mysql will then require mariadb to be installed, but having both mariadb and MySQL at the same time is not going to work unless the files in the mariadb packages are renamed. I also think that this is not what FESCo decided. As I understand the FESCo meeting minutes [2], the versioned obsolete is there to make it possible for existing users to continue using MySQL if the package is still actively maintained. The approach you describe will move all users away from MySQL on upgrade, and they have to follow the recipe above to get back to the packages they had before. That will cause a lot of confusion. Regards, Norvald H. Ryeng [1] https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB [2] http://meetbot.fedoraproject.org/teams/fesco/fesco.2013-01-30-18.01.log.html#l-313 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
On Wed, Mar 6, 2013 at 2:35 PM, Norvald H. Ryeng norvald.ry...@oracle.com wrote: In practice, this means that it will be almost impossible to install MySQL in Fedora. The recipe in the feature page [1] requires the user to 1. edit yum.conf to set excludes=mariadb* and obsoletes=0, 2. run yum shell to replace the packages, and 3. edit yum.conf again to remove obsoletes=0. I think that the above recipe wasn't updated for the package rename; with the new name, a simple yum install MySQL should work. Honza, is that how it was designed? If the MySQL packages don't provide mysql*, how can they fulfill dependencies? The FESCo decision from the minutes was: feature owners are asked to make it possible to install the MySQL stand-alone server (only) so dependencies on the client libraries are not a concern; Fedora packages are expected to use the MariaDB client libraries. Everything that depends on mysql will then require mariadb to be installed, but having both mariadb and MySQL at the same time is not going to work unless the files in the mariadb packages are renamed. File conflicts within the server packages might still be a concern, I don't know. Per the decision quoted above, FESCo would prefer the maintainers of the two servers to agree on a solution. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130306 changes
Compose started at Wed Mar 6 08:15:15 UTC 2013 Broken deps for x86_64 -- [HippoDraw] HippoDraw-python-1.21.3-6.fc19.x86_64 requires libboost_python.so.1.50.0()(64bit) [condor] condor-plumage-7.9.1-0.1.fc19.4.x86_64 requires libboost_system.so.1.50.0()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) [couchdb] couchdb-1.2.1-2.fc19.x86_64 requires libicuuc.so.49()(64bit) couchdb-1.2.1-2.fc19.x86_64 requires libicui18n.so.49()(64bit) couchdb-1.2.1-2.fc19.x86_64 requires libicudata.so.49()(64bit) [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [fawkes] fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5 fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit) fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2 fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires libclipsmm.so.2()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libgeos-3.3.6.so()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_signals-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) [fcitx-keyboard] fcitx-keyboard-0.1.3-1.fc18.x86_64 requires libicuuc.so.49()(64bit) [fcitx-libpinyin] fcitx-libpinyin-0.2.1-2.fc19.x86_64 requires libpinyin.so.2(LIBPINYIN)(64bit) fcitx-libpinyin-0.2.1-2.fc19.x86_64 requires libpinyin.so.2()(64bit) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [freeipa] freeipa-server-strict-3.1.2-3.fc19.x86_64 requires krb5-server = 0:1.11 [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdcm] gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26 gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit) [gedit-valencia] gedit-valencia-0.3.0-11.20120430gite8a0f500555be.fc18.x86_64 requires libvala-0.18.so.0()(64bit) [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [grass] grass-6.4.2-7.fc19.x86_64 requires libgeos-3.3.7.so()(64bit) grass-libs-6.4.2-7.fc19.i686 requires libgeos-3.3.7.so grass-libs-6.4.2-7.fc19.x86_64 requires libgeos-3.3.7.so()(64bit) [jetty] jetty-annotations-9.0.0-0.2.RC2.fc19.noarch requires mvn(org.eclipse.jetty.orbit:org.objectweb.asm) jetty-annotations-9.0.0-0.2.RC2.fc19.noarch requires mvn(org.eclipse.jetty.orbit:javax.annotation) jetty-jndi-9.0.0-0.2.RC2.fc19.noarch requires mvn(org.eclipse.jetty.orbit:javax.mail.glassfish) jetty-jsp-9.0.0-0.2.RC2.fc19.noarch requires mvn(org.eclipse.jetty.orbit:org.apache.taglibs.standard.glassfish) jetty-jsp-9.0.0-0.2.RC2.fc19.noarch requires mvn(org.eclipse.jetty.orbit:javax.servlet.jsp.jstl) jetty-jsp-9.0.0-0.2.RC2.fc19.noarch requires mvn(org.eclipse.jetty.orbit:com.sun.el) [kdevelop-python] kdevelop-python-1.4.1-2.fc19.i686 requires libpython2.7-kdevelop.so.1.0 kdevelop-python-1.4.1-2.fc19.x86_64 requires libpython2.7-kdevelop.so.1.0()(64bit) [libgda] 1:libgda-tools-5.1.1-4.fc19.x86_64 requires libgraph.so.5()(64bit) [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-uml-0.3.0-3.fc19.i686 requires
Re: Error dependencies
FIxed. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
guidance needed for rebuilding an RPM
I need some help/guidance on how to re-build a (normally) distributed package (net-snmp) using the latest Fedora spec file, but using the latest (upstream git head) version of the source; or alternatively, the current Fedora version _with my_ fix applied. You see, it may be some time before upstream 'officially' releases the next version, let alone when Fedora (RHEL, SUSE, etc.) release a new package too... but my production systems need the fixes now! Who is the net-snmp package maintainer? TIA Fulko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: guidance needed for rebuilding an RPM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed 06 Mar 2013 09:02:36 AM EST, Fulko Hew wrote: I need some help/guidance on how to re-build a (normally) distributed package (net-snmp) using the latest Fedora spec file, but using the latest (upstream git head) version of the source; or alternatively, the current Fedora version _with my_ fix applied. You see, it may be some time before upstream 'officially' releases the next version, let alone when Fedora (RHEL, SUSE, etc.) release a new package too... but my production systems need the fixes now! Who is the net-snmp package maintainer? Your best bet would be to open a Bugzilla ticket against the net-snmp package with a pointer to the upstream patch that you want applied, as well as reasoning why it's important to have it before the next upstream release. Usually most packagers will apply the patch and submit an update for Fedora. If it's urgent for RHEL or SUSE, you should also contact your paid support representative there and make a request that they release an errata update. That said, for applying a patch to the source locally, you probably want to install the 'fedora-packager' package and then clone the net-snmp build tree. fedpkg clone net-snmp Then you can modify the spec file in that directory, have it apply your patch and then run fedpkg local which will build the package locally. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE3TcgACgkQeiVVYja6o6PfxwCgoMiVpk/YbjN0pnKkbyK1RY+o 2+kAoKbucC2eE8M0dRj+jWsndiStIAMh =GCSE -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora openid provider (fas-openid) in service
On Wed, 06 Mar 2013 08:32:27 +0100 Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, 2013-03-05 at 23:39 -0700, Kurt Seifried wrote: can I use my existing openid? kurt.seifried.org. If you run your own openid server then of course you can use your openid to login on website that requires *an* openid (ask.fp.o, stackoverflow, pypi...). However, in the futur, a number of the Fedora-specific web-application will require you to login using your Fedora specific openid, there another openid that the one provided by fas-openid simply won't work. To expand on that, openid allows for 'extensions' and we will likely use some with our applications. In particular an extension to know if the identity has signed the FPCA, or if the identity is in a particular group. If you want better technical background on openid, Patrick did an excellent classroom session on it not long ago for us: http://meetbot.fedoraproject.org/fedora-classroom/2013-02-22/fas-openid-class.2013-02-22-18.00.html kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)
On Mon, Mar 04, 2013 at 02:15:30PM +0100, Mark Wielaard wrote: Hi, I am looking for some valgrind users that want to try out the latest valgrind package in rawhide. If you use valgrind please try out the new valgrind-3.8.1-10.fc19 version in rawhide. It is the first version that puts the debuginfo in a separate valgrind-debuginfo package (this saves ~35MB from the main packages). http://koji.fedoraproject.org/koji/buildinfo?buildID=399059 Upstream used to recommend against stripping debuginfo from the valgrind vg preload libraries because it produced less usable warning/error messages. But since a long time now valgrind intercepts are done in a different way and just having the dynsym symbols around should be enough. Please let me know (or file a bug report) if using the new valgrind package from rawhide gives less useful warnings/errors (and whether installing valgrind-debuginfo solves any of such issues). I tested valgrind-3.8.1-10.fc19.x86_64 (without valgrind-debuginfo). It appears to work fine. There's no noticable difference between this version and earlier versions. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Tue, Mar 5, 2013 at 11:30 PM, Kevin Kofler kevin.kof...@chello.at wrote: Miloslav Trmač wrote: We also propose to build up automated tests to verify the tier 1 and tier 2 functionality, and use those tests on newly-built packages to gate inclusion in rawhide. Please no! Extending the already painful red tape we have in stable releases to Rawhide will completely stall development! I think this would require very little red tape; certainly not the 14-day wait that bodhi typically imposes. If a new package doesn't break tests, it will tagged into rawhide immediately or overnight - just like now. No extra work needed, no change in workflow. If a new package does break tier 1/2 tests, yes, the rawhide gate requires a change in the workflow: the breakage must be fixed now. OTOH the breakage will have to be fixed _anyway_; the tests will make it: 1) easier to spot (we wouldn't need to rely on manual testing) 2) easier to diagnose (we would know fairly precisely what has changed between the working and broken version, and it would be a fairly small set of packages) 3) much better for everyone else working within rawhide. All of these should save time for everybody involved. Yes, the rawhide gate may mean more work now, but overall shouldn't require extra work for package owners. (It may require extra work for Change owners that implies updating the tests.) And it's all the more ridiculous that this is being proposed after we allowed the team for one of our most core components (Anaconda) to KNOWINGLY break its functionality in Rawhide, forcing a release slip. I don't think there is any obvious reason to exempt anaconda from this process. Of course, we start with zero tests, and thus also zero requirements on anaconda; OTOH I expect somebody will propose to add a test that minimal network install should always be working very soon after the infrastructure is ready. Such a test would obviously apply both to anaconda updates and to changes of everything else that may break anaconda. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora openid provider (fas-openid) in service
- Original Message - On 05/03/13 10:39 PM, Kurt Seifried wrote: can I use my existing openid? kurt.seifried.org http://kurt.seifried.org. That's not really a question that makes sense. Fedora runs an OpenID provider which gives you an OpenID associated with your 'Fedora identity' - ultimately, it's backed by your FAS account. Your own OpenID is a completely different identity. The idea of 'using' your 'existing' OpenID with Fedora's OpenID provider is just not an idea that is compatible with how OpenID works. A lot of OpenID aware sites offers you possibility to bind your OpenID with the local account. And yes, sometimes it leads to strange results (based on how bad you implemented it). Last time I tried it with one local e-shop I ended in some account limbo ;-) R. -- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 914285] perl-HTML-TableExtract: FTBFS in rawhide
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=914285 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|nott...@redhat.com |psab...@redhat.com -- 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=4R9zSEfhH0a=cc_unsubscribe -- 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: Testing valgrind in rawhide (separate valgrind-debuginfo package)
BTW can you clear up a peculiarity I've noticed in valgrind in Rawhide? The symbols reported in the stack traces seem to be mangled in a strange way, eg: ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6 ==11843==at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11843==by 0x38EAC861F9: strdup (strdup.c:42) ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241) ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274) ==11843==by 0x400955: main (in /tmp/test) The symbol we're actually calling is 'setsockcreatecon'. It's not a macro. There is no public function called 'setprocattrcon' (although there is an internal function of that name and setsockcreatecon only calls this internal functions so there could be some inlining going on). And what's with the '.constprop.2' suffix? In any case, this is a problem because in my valgrind suppressions file I have to list the mangled name, not the real name. Test program is here if you want to try it: https://bugzilla.redhat.com/show_bug.cgi?id=918572 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 914285] perl-HTML-TableExtract: FTBFS in rawhide
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=914285 --- Comment #1 from Petr Šabata psab...@redhat.com --- BRs are all wrong. I'll also update this to 2.11. The package also basically needs HTML::ElementTable which is not in Fedora yet. I'll package that, too. -- 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=6hJrQ9ljmAa=cc_unsubscribe -- 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: New Fedora openid provider (fas-openid) in service
On Wed 06 Mar 2013 09:24:02 AM EST, Jaroslav Reznik wrote: - Original Message - On 05/03/13 10:39 PM, Kurt Seifried wrote: can I use my existing openid? kurt.seifried.org http://kurt.seifried.org. That's not really a question that makes sense. Fedora runs an OpenID provider which gives you an OpenID associated with your 'Fedora identity' - ultimately, it's backed by your FAS account. Your own OpenID is a completely different identity. The idea of 'using' your 'existing' OpenID with Fedora's OpenID provider is just not an idea that is compatible with how OpenID works. A lot of OpenID aware sites offers you possibility to bind your OpenID with the local account. And yes, sometimes it leads to strange results (based on how bad you implemented it). Last time I tried it with one local e-shop I ended in some account limbo ;-) I encountered an issue recently with pypi.org, where it was treating http://sgallagh.id.fedoraproject.org and https://sgallagh.id.fedoraproject.org as separate accounts (up to a point where they were causing tracebacks because they shared the same email address). So lesson learned: always drop the protocol prefix. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)
On Wed, 2013-03-06 at 14:38 +, Richard W.M. Jones wrote: BTW can you clear up a peculiarity I've noticed in valgrind in Rawhide? The symbols reported in the stack traces seem to be mangled in a strange way, eg: ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6 ==11843==at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11843==by 0x38EAC861F9: strdup (strdup.c:42) ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241) ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274) ==11843==by 0x400955: main (in /tmp/test) The symbol we're actually calling is 'setsockcreatecon'. It's not a macro. There is no public function called 'setprocattrcon' (although there is an internal function of that name and setsockcreatecon only calls this internal functions so there could be some inlining going on). And what's with the '.constprop.2' suffix? Right, there is something like inlining going on. Though not actual inlining, more like calling specialied variants of the function. Some GCC hacker might correct me if I get the details wrong. But I think this is just caused by (better) optimization of GCC 4.8 in rawhide. As far as I understand it GCC sees that setsockcreatecon (NULL) is really setprocattrcon with some constant arguments call. The src/procattr.c definition of all_selfattr_def(sockcreatecon, sockcreate) make it a little hard to see exactly, but obviously GCC knows. For example the pid argument will always be zero. Because of this GCC creates a specialized constant propagation function based on setprocattrcon called setprocattrcon.constprop.somenumber. And as far as I can see that is the actual function that the setsockcreatecon function PLT entry points to. (And this setprocattrcon.constprop.2 then calls a specialized constant propagation function version of setprocattrcon_raw.) In any case, this is a problem because in my valgrind suppressions file I have to list the mangled name, not the real name. It looks like you will have to use the setprocattrcon[.constprop] function name in your suppression file. I am not exactly sure how the linker ends up pointing directly to that one for setsockcreatecon (), but it apparently is. And so valgrind will only know it by that name. Sorry. Note that you can let valgrind create the suppression for you with --gen-suppressions=yes. And you can also use wildcards in suppressions like fun:setprocattrcon.constprop.*. Cheers, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 867266] perl-Crypt-OpenSSL-DSA-0.14 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=867266 --- Comment #1 from Wes Hardaker wjhns...@hardakers.net --- pushed a while ago. 0.14 is current in most branches. -- 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=SV9PDPhUdHa=cc_unsubscribe -- 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
[Bug 867266] perl-Crypt-OpenSSL-DSA-0.14 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=867266 Wes Hardaker wjhns...@hardakers.net changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution|--- |NOTABUG Last Closed||2013-03-06 10:16:08 -- 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=N7IBBIojMGa=cc_unsubscribe -- 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: eigen3 license change
On Wed, Mar 6, 2013 at 6:29 AM, Rich Mattes richmat...@gmail.com wrote: Hi all, I have updated the eigen3 package[1] to release 3.1.2 in rawhide. This update comes with a license change: eigen3 is now licensed as MPLv2.0 with parts licensed as LGPLv2+ and BSD. Affected packages include: fawkes (GPLv2+ and GPLv2+ with exceptions) [Pulled into via a development metapackage, not actually built into fawkes] mrpt (GPLv3+) pcl (BSD) sympol (GPLv2+) I'll take care of sympol. Thanks for the heads-up. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 867266] perl-Crypt-OpenSSL-DSA-0.14 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=867266 Wes Hardaker wjhns...@hardakers.net changed: What|Removed |Added Resolution|NOTABUG |CURRENTRELEASE -- 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=xkzcuysGjTa=cc_unsubscribe -- 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
[Bug 914285] perl-HTML-TableExtract: FTBFS in rawhide
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=914285 Petr Šabata psab...@redhat.com changed: What|Removed |Added Depends On||918612 -- 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=zUekWSLLYra=cc_unsubscribe -- 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
File perl-NOCpulse-Utils-1.14.12.tar.gz uploaded to lookaside cache by msuchy
A file has been added to the lookaside cache for perl-NOCpulse-Utils: c454ff9f71e9a1d0aff2aa6be00c384b perl-NOCpulse-Utils-1.14.12.tar.gz -- 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: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Wed, 06 Mar 2013 19:26:13 +0700, Michel Alexandre Salim wrote: Would be good if emacs-rpm-spec-mode could be kept. Taking it over. Great! Thanks. -- Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc0.git15.1.fc19.x86_64 loadavg: 0.31 0.21 0.24 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: guidance needed for rebuilding an RPM
On Wed, Mar 6, 2013 at 3:08 PM, Stephen Gallagher sgall...@redhat.comwrote: That said, for applying a patch to the source locally, you probably want to install the 'fedora-packager' package and then clone the net-snmp build tree. fedpkg clone net-snmp Then you can modify the spec file in that directory, have it apply your patch and then run fedpkg local which will build the package locally. I just tried fedpkg and failed duo to permissions, so I just want to mention that you can get the SRPM from koji at http://koji.fedoraproject.org/koji/buildinfo?buildID=386408 /Palle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Mar 5, 2013 at 5:52 PM, Michal Schmidt mschm...@redhat.com wrote: On 03/04/2013 04:01 PM, Matt Domsch wrote: drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; I think sfc does not really *need* to set dev_id. Yes, these are multi-port cards, but the ports are on distinct PCI functions. Which actually means they should leave it alone then, and not do anything. The dev_id stuff is really not to be used across different parent devices. If there is any order unpredictable probing order enumeration logic involved in the driver spanning multiple parents, using dev_id will actually break things and not help anything. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
-Original Message- From: devel-boun...@lists.fedoraproject.org [mailto:devel- boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt Sent: Tuesday, March 05, 2013 10:22 PM To: devel@lists.fedoraproject.org Subject: Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names On 03/04/2013 04:01 PM, Matt Domsch wrote: drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; I think sfc does not really *need* to set dev_id. Yes, these are multi-port cards, but the ports are on distinct PCI functions. I think setting of 'dev_id' by drivers/devices used in enterprise server environment will be beneficial, not just for devices in which multiple ports share a single PCI d/b/d/f(1 PCI d/b/d/f - 2 ports), also for multiport devices with 1 PCI d/b/d/f - 1 Port mapping. The following scenarios demonstrate the requirement/usefulness - 1. As the dev_id would indicate the physical port number used by a netdevice and will be available to user space via sysfs, tools such as NetworkManager could use the information to implement intelligent/smarter bonding of netdevices. For example, when bonding netdevices coming from NIC partitions (or SR-IOV VFs) which use the same physical port, in fault tolerance mode for example, NM could inform the user that the netdevices being enslaved map to/use the same physical port and bonding them may not have desired effect. Dev_id would provide such information in a generic way. 2. biosdevname could possibly use 'dev_id' to determine the port part of pslotpport eliminating the need to determine/enumerate port number as pointed out here. With regards, Narendra K -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: guidance needed for rebuilding an RPM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2013 11:07 AM, Palle Ravn wrote: On Wed, Mar 6, 2013 at 3:08 PM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com wrote: That said, for applying a patch to the source locally, you probably want to install the 'fedora-packager' package and then clone the net-snmp build tree. fedpkg clone net-snmp Then you can modify the spec file in that directory, have it apply your patch and then run fedpkg local which will build the package locally. I just tried fedpkg and failed duo to permissions, so I just want to mention that you can get the SRPM from koji at http://koji.fedoraproject.org/koji/buildinfo?buildID=386408 /Palle Try fedpkg clone --anonymous net-snmp That's the read-only clone. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE3cPkACgkQeiVVYja6o6Mf5gCfcz1GzT5elRHtNui1evOcj2bm +vgAnRPZUw/OhvLPJ6AC9RN/aMnvF2kf =Ofp9 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mediawiki 1.20.2 has landed
On Tue, 2013-03-05 at 15:23 -0600, Michael Cronenworth wrote: Michael Cronenworth wrote: I was not able to use your updated package as the latest version of semantics now requires the Validator[1] extension. [1] http://semantic-mediawiki.org/wiki/Validator More specifically: Validator = 0.5. Fedora has 0.4.13. http://semantic-mediawiki.org/wiki/Help:Installation#Requirements Thanks for the feedback. Updated --scratch packages available for consideration ... * Rawhide * mediawiki-validator - http://koji.fedoraproject.org/koji/taskinfo?taskID=5084914 * mediawiki-semantic - http://koji.fedoraproject.org/koji/taskinfo?taskID=5084947 * Fedora 18 * mediawiki-validator - http://koji.fedoraproject.org/koji/taskinfo?taskID=5086055 * mediawiki-semantic - http://koji.fedoraproject.org/koji/taskinfo?taskID=5086060 Thanks, James 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 ARM weekly status meeting 2013-03-06
Good Afternoon all, Please join us today (Wednesday, March 6th) at 4PM EST (9PM 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) Aarch64 patching 3) Managing changes in Uboot and boot scripts 4) Arm Koji status update 5) ARM Tech Talks - suggestions for future talks, volunteers? 6) 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. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo Meeting (2013-03-06)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 === #fedora-meeting: FESCO (2013-03-06) === Meeting started by sgallagh at 18:00:07 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-03-06/fesco.2013-03-06-18.00.log.html . Meeting summary - --- * init process (sgallagh, 18:00:07) * #1093 announce fesco tickets on #fedora-devel (sgallagh, 18:03:44) * AGREED: Try out announcing FESCo ticket open/close in #fedora-admin (8 +1, 1 0, 0 -1) (sgallagh, 18:12:13) * Next week's chair (sgallagh, 18:12:33) * notting to chair next week's meeting (sgallagh, 18:14:52) * Open Floor (sgallagh, 18:15:00) * ACTION: sgallagh to open FESCo ticket to track the Fedora Revamp discussion (sgallagh, 18:45:18) * AGREED: Discuss Fedora Revamp on de...@lists.fp.o for another week and revisit at the next meeting (6 +1, 0 0, 0 -1) (sgallagh, 18:46:05) * AGREED: draft a schedule to look at, revisit next week or entertain counterproposals for approving a schedule then (7 +1, 0 0, 0 -1) (sgallagh, 19:11:56) Meeting ended at 19:16:19 UTC. Action Items - * sgallagh to open FESCo ticket to track the Fedora Revamp discussion Action Items, by person - --- * sgallagh * sgallagh to open FESCo ticket to track the Fedora Revamp discussion * **UNASSIGNED** * (none) People Present (lines said) - --- * sgallagh (63) * nirik (60) * jwb (60) * mitr (26) * t8m (20) * abadger1999 (16) * jreznik (13) * pjones (11) * notting (11) * tflink (7) * mmaslano (5) * zodbot (5) * drago01_ (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE3loAACgkQeiVVYja6o6MgrgCff9ytoT2hmjFLkIhw3g29dnu4 3UMAnide0KqB45M4DkFMhaS7FLnxPQLG =Alrh -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Yubikey single-factor authentication disabled
Hi folks, anyone else seeing Yubikey single-factor authentication has been disabled. when logging into fas or any other fas based services? I checked in fas and yubikey is enabled for my account (and has been for years). Test auth in fas works. Regards, Andreas -- BR Andreas Bierfert, M.Sc. | phone: +49 6897 1721738 | GPG: C58CF1CB andreas.bierf...@lowlatency.de | fax: +49 6897 1722828 | signed/encrypted http://lowlatency.de | cell: +49 170 9665206 | mail preferred signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikey single-factor authentication disabled
On Wed, 6 Mar 2013 20:58:00 +0100 Andreas Bierfert andreas.bierf...@lowlatency.de wrote: Hi folks, anyone else seeing Yubikey single-factor authentication has been disabled. when logging into fas or any other fas based services? I checked in fas and yubikey is enabled for my account (and has been for years). Test auth in fas works. Yes, we disabled this and were not good about communicating that that change went live with our last fedora account system update. ;( We were meaning to change the error it outputs to go to a wiki page so we could communicate the change there, but we have not had a chance to push that change live to production. Basically the reasons are: 1) allowing yubikeys as a 1 factor auth means that anyone who gains access to your yubikey and who knows your fedora account system login can do anything they like with your account. 2) It's confusing to some people because they think Oh, I am using a hardware device here, this must be 2 factor! when it's not. We are hoping to enable real 2 factor with our applications, but haven't yet been able to do so. ;( Sorry for the trouble kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
- Original Message - Gnome maintainers: https://admin.fedoraproject.org/pkgdb/acls/name/polkit-gnome Complete orphan. Please add yourselves (halfline, mclasen, ajax, mcann, whoever is interested) We don't need polkit-gnome anymore, gnome-shell has its own polkit agent builtin. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] please review: Ticket 588 - create MAN pages for command line scripts
https://fedorahosted.org/389/ticket/588 https://fedorahosted.org/389/attachment/ticket/588/0001-Ticket-588-Create-MAN-pages-for-command-line-scripts.patch -- Mark Reynolds Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: RFC: Fedora revamp proposal
Colin Walters (walt...@verbum.org) said: On Tue, 2013-03-05 at 16:58 -0500, Bill Nottingham wrote: We don't ship in a way that easily allows this though, now. Admittedly, this is due to the sheer *amount* of stuff involved in just maintaining single versions of things, and how much that would jump if we started having multiple versions available all the time. To be clear, I am not suggesting multiple versions. The suggestion is that the old version of mesa overrides the new version and the tests (and users) get it. Pretend like we bumped the Epoch. That requires more tooling changes, of course. (Or really dirty tricks in the repodata). Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
Steve Clark (scl...@netwolves.com) said: Well you can be as sarcastic as you want but I have been using UNIX/Linux since 1985 and never had init hang or die on me. sysvinit and systemd have linked against libselinux since SELinux policy was introduced. upstart only didn't because policy was loaded in the initramfs then, which was arguably a mistake. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting minutes 2013-03-06
Thanks to those who were able to join us for the weekly status meeting today.
For those that were unable, the minutes are posted below:
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-03-06/fedora-meeting-1.2013-03-06-21.00.html
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-03-06/fedora-meeting-1.2013-03-06-21.00.txt
Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-03-06/fedora-meeting-1.2013-03-06-21.00.log.html
Paul
===
#fedora-meeting-1: Fedora ARM weekly status meeting
===
Meeting started by pwhalen at 21:00:17 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-03-06/fedora-meeting-1.2013-03-06-21.00.log.html
.
Meeting summary
---
* 0) Status of ACTION items from our previous meeting (pwhalen,
21:02:12)
* Meeting Minutes from last week: (pwhalen, 21:02:22)
* LINK:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-02-27/fedora-meeting-1.2013-02-27-21.00.html
(pwhalen, 21:02:23)
* bconoboy COMPLETE - list of packages needing aarch64-specific
configurey updates. Email sent to the mailing list today, initial
package list: (pwhalen, 21:02:35)
* LINK:
http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs
(pwhalen, 21:02:35)
* jonmasters COMPLETE - pbrobinson to apply jonmasters' mongodb patch.
Failed to build - dmarlin investigating (pwhalen, 21:02:53)
* pbrobsinson INPROGRESS - review vboot by the end of the weekend
(pwhalen, 21:03:04)
* ACTION: jonmasters to file LLVM bug and send link to the mailing
list (pwhalen, 21:04:21)
* 1) Problem Packages (pwhalen, 21:05:56)
* top-pegasus and java are the biggest blockers right now (bconoboy,
21:08:38)
* java team is working on java (bconoboy, 21:08:50)
* ACTION: pbrobinson/bconoboy investigating top-pegasus (bconoboy,
21:09:09)
* rawhide statistics: {'older': 2008, 'local_only': 2, 'remote_only':
262, 'same': 10919, 'newer': 2, 'total_missing_builds': 2821}
(bconoboy, 21:09:46)
* mass rebuild more-or-less done, but koji-shadow has not run to
completion yet (bconoboy, 21:10:03)
* Python hackers welcome to work on koji-shadow stability (bconoboy,
21:13:19)
* 2) Aarch64 patching (pwhalen, 21:13:50)
* LINK:
http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs
(pwhalen, 21:15:02)
* LINK:
https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plaincollctn_list=devel
(nirik, 21:38:38)
* LINK: Critical path list is
https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plaincollctn_list=devel
(bconoboy, 21:39:53)
* ACTION: bconoboy and dmarlin to do before/after patchify builds on
critical path packages to demonstrate safety (bconoboy, 21:40:31)
* ACTION: jonmasters to followup with what Debian and OpenSuSE did for
automated patching (jonmasters, 21:41:02)
* ACTION: bconoboy to write fesco ticket (bconoboy, 21:44:07)
* 3) Managing changes in Uboot and boot scripts (pwhalen, 21:44:48)
* LINK: https://fedorahosted.org/arm-boot-config/ (dgilmore,
21:58:55)
* LINK: dgilmore has started a new package,
https://fedorahosted.org/arm-boot-config/ (bconoboy, 21:59:15)
* ACTION: jonmasters to reply to the fedora list with his dtb idea
(bconoboy, 22:02:20)
* 4) Arm Koji status update (pwhalen, 22:02:58)
* ARM network almost ready to go for the 3 other chassis (bconoboy,
22:04:39)
* 5) ARM Tech Talks - suggestions for future talks, volunteers?
(pwhalen, 22:06:11)
* please send ideas for future tech talks to the list (pwhalen,
22:06:45)
* 6) Open floor (pwhalen, 22:08:01)
Meeting ended at 22:16:19 UTC.
Action Items
* jonmasters to file LLVM bug and send link to the mailing list
* pbrobinson/bconoboy investigating top-pegasus
* bconoboy and dmarlin to do before/after patchify builds on critical
path packages to demonstrate safety
* jonmasters to followup with what Debian and OpenSuSE did for automated
patching
* bconoboy to write fesco ticket
* jonmasters to reply to the fedora list with his dtb idea
Action Items, by person
---
* bconoboy
* pbrobinson/bconoboy investigating top-pegasus
* bconoboy and dmarlin to do before/after patchify builds on critical
path packages to demonstrate safety
* bconoboy to write fesco ticket
* jonmasters
* jonmasters to file LLVM bug and send link to the mailing list
* jonmasters to followup with what Debian and OpenSuSE did for
automated patching
* jonmasters to reply to the fedora list with his dtb idea
* pbrobinson
* pbrobinson/bconoboy investigating top-pegasus
* **UNASSIGNED**
* (none)
People Present (lines said)
---
* bconoboy (99)
* jonmasters (93)
* pbrobinson (69)
* dgilmore (40)
* j_dulaney
Re: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]
On 04/03/13 02:51 PM, Mark McLoughlin wrote: On Thu, 2012-12-06 at 07:06 -0800, Adam Williamson wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. It's interesting that you call out Java and Ruby folks as being heretics. I guess that means all is kosher with Python? Holy four month old thread revival, Batman! Why yes it does indeed mean that, since as you know, anyone in Fedora will tell you that I am _the_ person to go to for an encyclopaedic knowledge of software development, seeing as how I am the QA monkey, don't know how to write code, and don't develop any software ;) (That was a snarky way of saying, no, it doesn't mean that, it just means I was not aware of any issues like the one you describe below.) OpenStack is getting burned by API instability in some Python packages, so I've started a thread on Python's distutils-sig to try and guage the level of heresy amongst Python folks :) Two things I'm picking up from the thread: - A trend towards semantic versioning and, implicit in that, an acceptance of API breakages so long as the major number of a library version is incremented - Supporting the parallel installation of incompatible versions of libraries isn't seen as an issue because you can just use virtual environments ... which amounts to Python Software Collections. The combination of those two things suggests to me that the Python world will start looking a lot less sane to packagers - i.e. library maintainers breaking API compatibility more often and assuming we can just use SC or similar to have multiple incompatible versions installed. Well, that sounds pretty bad. You may sign my name to the Less Of This Nonsense petition with my blessing... -- 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
New list for QA development: qa-devel
It occurred to me that it's just possible someone might find this interesting but not be subscribed to test@, so I thought I'd mention it here. We have recently created the new list 'qa-devel at lists.fedoraproject.org' for discussion of QA tool development. It will subsume the autoqa-devel list, but it also covers other tools being developed by and mostly for the QA team, including the blocker bug webapp and the blocker bug submission tool. So...if it interests you...check it out :) -- 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
Re: RFC: Fedora revamp proposal
On 06/03/13 04:40 AM, Jaroslav Reznik wrote: - Original Message - On Tue, 5 Mar 2013 03:48:29 -0500 (EST) From tooling perspective - that's the question if we want to enhance our tools, step into other similar project (for collaboration with our downstreams? other distros...). yeah, I don't know. Perhaps someone could ask around and see if there's any projects/setups inside Red Hat that would be good for this? ABI checking and perhaps rpm diffing? I'm trying to ask guys around, what do they have and what they could offer for us. And sell it as a good thing for both sides ;-) We do already have an AutoQA test which runs rpmguard, and rpmguard notes dependency/provision version changes. Here it is spotting an ABI bump for binutils: http://autoqa.fedoraproject.org/results/531743-autotest/qa02.qa/rpmguard/results/binutils-2.23.52.0.1.html Now, whether you'd want to somehow parse such results out from the existing rpmguard test externally, or write a new more specific test, or do something else, or dance a little jig, is a different question. But to a certain extent we're Already Doing That. The rpmguard test is currently entirely informational, no policies are enforced, but you can go read the output if you want to be an informed package maintainer... -- 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
Re: RFC: Fedora revamp proposal
On 04/03/13 10:18 AM, Miloslav Trmač wrote: This is a proposal of changes to the way future Fedora cycles should work and integrate changes. So just a couple of notes on the proposal: It's phrased in very technical terms here - probably a wise choice - but I think it's worth noting one of the angles we took in discussing it in person at FUDCon is that it has the potential to contribute to the more general idea of making Fedora more flexible in terms of what we can build and release. It has the effect of giving us a defined 'core' of functionality on top of which we could build various things. It would only be one piece of a larger puzzle here - things like better image building tools and Formulas are part of the same puzzle - but it's an element I was quite interested in. Also, I recall the in-person discussions making it clearer that this plan is pretty strongly dependent on automated testing. This has been discussed somewhat in the follow-ups, but to make sure it's very clear, my reading of the proposal is that it would require substantially more sophisticated and reliable tests than we currently have in AutoQA, and we'd need development resources - either RH paid, or volunteer - to build AutoQA up to the point where it could support this plan without causing unnecessary disruption. -- 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
Re: Mediawiki 1.20.2 has landed
On 03/06/2013 10:41 AM, James Laska wrote: * Fedora 18 * mediawiki-validator - http://koji.fedoraproject.org/koji/taskinfo?taskID=5086055 * mediawiki-semantic - http://koji.fedoraproject.org/koji/taskinfo?taskID=5086060 These packages seemed to work fine on my mediawiki. I have not used this extension before but I enabled it and the Special pages appeared with no visible errors. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New list for QA development: qa-devel
A lot of wiki page should be updated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On 06/03/13 04:39 AM, Dan Mashal wrote: Took libindicator too. Is this deprecated upstream? No, there are commits right up to late Feb in launchpad. But then I don't immediately see that you'd want it for MATE purposes (or really any other Fedora purposes); it's a Unity thing. I packaged and used to own it for my aborted plan to try and package Unity, and it's orphaned because I don't want it any more. I don't think it has any dependencies in Fedora, and I think it's pretty useless if you're not running Unity. bamf is in a similar position, but at least _something_ - gnome-pie, whatever that is - requires it. So it might actually be more useful for someone to pick that 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
Re: New Fedora openid provider (fas-openid) in service
On 06/03/13 06:41 AM, Stephen Gallagher wrote: I encountered an issue recently with pypi.org, where it was treating http://sgallagh.id.fedoraproject.org and https://sgallagh.id.fedoraproject.org as separate accounts (up to a point where they were causing tracebacks because they shared the same email address). So lesson learned: always drop the protocol prefix. The Verge does the same...the lesson I chose to learn was just to always use https, though. -- 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
Re: New Fedora openid provider (fas-openid) in service
On 06/03/13 06:24 AM, Jaroslav Reznik wrote: - Original Message - On 05/03/13 10:39 PM, Kurt Seifried wrote: can I use my existing openid? kurt.seifried.org http://kurt.seifried.org. That's not really a question that makes sense. Fedora runs an OpenID provider which gives you an OpenID associated with your 'Fedora identity' - ultimately, it's backed by your FAS account. Your own OpenID is a completely different identity. The idea of 'using' your 'existing' OpenID with Fedora's OpenID provider is just not an idea that is compatible with how OpenID works. A lot of OpenID aware sites offers you possibility to bind your OpenID with the local account. And yes, sometimes it leads to strange results (based on how bad you implemented it). Last time I tried it with one local e-shop I ended in some account limbo ;-) Sure, but that's not at all the same thing as 'using' an OpenID with *another* OpenID. That's not a concept that makes any sense. Linking an OpenID with an account for some service makes perfect sense; it's really just saying 'I declare that this OpenID should be able to authenticate to this account'. It would be a Possible Thing for Fedora to say 'you can log in to Fedora services using third-party OpenIDs'. We don't do that now, but we could. But there's no way we could say 'you can use your external OpenID with your Fedora OpenID'. It's like when you try to use the rubber duck with the chewing gum in an adventure game, or something. The protagonist will just look at you funny and pass a sarcastic remark. ;) (Random thought: Wordpress both acts as an OpenID provider and allows you to log in via OpenID. I have not yet been brave enough to see what happens if I try to log in to my blog using the OpenID that it provides for the admin account. I suspect the answer may be 'The Singularity'...:) -- 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
Re: New list for QA development: qa-devel
On 06/03/13 07:11 PM, Christopher Meng wrote: A lot of wiki page should be updated. That is a true statement. I am also strongly in favour of world peace. Would you like to be just a bit more...specific? Detailed? -- 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
Re: guidance needed for rebuilding an RPM
On 06/03/13 08:38 AM, Stephen Gallagher wrote: I just tried fedpkg and failed duo to permissions, so I just want to mention that you can get the SRPM from koji at http://koji.fedoraproject.org/koji/buildinfo?buildID=386408 /Palle Try fedpkg clone --anonymous net-snmp To avoid going through the whole discussion we had last week _again_ - as fedpkg is primarily a tool intended for and used by Fedora packagers, it defaults to trying to do an authenticated check out, so you can also commit changes to the package. People sometimes suggest making the --anonymous option the default so it doesn't fail if you're not actually a packager, but that would be optimising for the corner case, in this particular situation. -- 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
Re: [mirall] plasma client try3
On Wed, 6 Mar 2013 01:00:26 + (UTC)
Joseph Marrero jmarr...@fedoraproject.org wrote:
commit 868b82191f2627c6f34d64abb554b06e53de41fb
Author: Joseph Marrero jmarr...@fedoraproject.org
Date: Tue Mar 5 20:59:46 2013 -0400
plasma client try3
mirall.spec |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/mirall.spec b/mirall.spec
index 3ef7fd5..9a0bb17 100644
--- a/mirall.spec
+++ b/mirall.spec
@@ -97,7 +97,8 @@ fi
#remove libmirallsync on official merge
%{_libdir}/libmirallsync.so
%{_libdir}/libowncloudsync.so
-
+##for some reason this is unlinked in this mirall pull, in the
uptream version is working +/usr/lib/libowncloudsync.so
# re activate when officially merged#%{_libdir}/libowncloudsync.so.0
#%{_libdir}/libowncloudsync.so.%{version}
What are you trying to do here?
The x86_64 version of this package shouldn't ship any libraries
in /usr/lib/
Is this some issue with upstreams make install?
Why not manually install it in the right place?
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: [mirall] plasma client try3
From: Joseph Marrero jmarr...@gmail.com
Date: Wed, Mar 6, 2013 at 11:40 PM
Subject: Re: [mirall] plasma client try3
To: Kevin Fenzi ke...@scrye.com
I am preparing the package for upstream merge between mirall and
owncloud-plasma-client
This is are test builds, they are not going to be pushed to any kind of
updates until the official builds have been merged together
the issue with the lib is resolved in the current upstream but in the
owncloud-plasma-client is not.
Let me know if I should not make it build to test in the f19 repos.
On Wed, Mar 6, 2013 at 11:33 PM, Kevin Fenzi ke...@scrye.com wrote:
On Wed, 6 Mar 2013 01:00:26 + (UTC)
Joseph Marrero jmarr...@fedoraproject.org wrote:
commit 868b82191f2627c6f34d64abb554b06e53de41fb
Author: Joseph Marrero jmarr...@fedoraproject.org
Date: Tue Mar 5 20:59:46 2013 -0400
plasma client try3
mirall.spec |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/mirall.spec b/mirall.spec
index 3ef7fd5..9a0bb17 100644
--- a/mirall.spec
+++ b/mirall.spec
@@ -97,7 +97,8 @@ fi
#remove libmirallsync on official merge
%{_libdir}/libmirallsync.so
%{_libdir}/libowncloudsync.so
-
+##for some reason this is unlinked in this mirall pull, in the
uptream version is working +/usr/lib/libowncloudsync.so
# re activate when officially merged#%{_libdir}/libowncloudsync.so.0
#%{_libdir}/libowncloudsync.so.%{version}
What are you trying to do here?
The x86_64 version of this package shouldn't ship any libraries
in /usr/lib/
Is this some issue with upstreams make install?
Why not manually install it in the right place?
kevin
--
Joseph Marrero
--
Joseph Marrero
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Wed, 06 Mar 2013 18:31:06 -0800 Adam Williamson awill...@redhat.com wrote: We do already have an AutoQA test which runs rpmguard, and rpmguard notes dependency/provision version changes. Here it is spotting an ABI bump for binutils: http://autoqa.fedoraproject.org/results/531743-autotest/qa02.qa/rpmguard/results/binutils-2.23.52.0.1.html Now, whether you'd want to somehow parse such results out from the existing rpmguard test externally, or write a new more specific test, or do something else, or dance a little jig, is a different question. But to a certain extent we're Already Doing That. The rpmguard test is currently entirely informational, no policies are enforced, but you can go read the output if you want to be an informed package maintainer... Sure. Note however that we don't currently run autoqa on rawhide builds and that was at least the initial target for this. ;) But yeah, good test to know... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On 06/03/13 09:00 PM, Kevin Fenzi wrote: On Wed, 06 Mar 2013 18:31:06 -0800 Adam Williamson awill...@redhat.com wrote: We do already have an AutoQA test which runs rpmguard, and rpmguard notes dependency/provision version changes. Here it is spotting an ABI bump for binutils: http://autoqa.fedoraproject.org/results/531743-autotest/qa02.qa/rpmguard/results/binutils-2.23.52.0.1.html Now, whether you'd want to somehow parse such results out from the existing rpmguard test externally, or write a new more specific test, or do something else, or dance a little jig, is a different question. But to a certain extent we're Already Doing That. The rpmguard test is currently entirely informational, no policies are enforced, but you can go read the output if you want to be an informed package maintainer... Sure. Note however that we don't currently run autoqa on rawhide builds and that was at least the initial target for this. ;) Um. I think we do? I see results from rpmguard (and other tests) for builds with 'fc19' in them at http://autoqa.fedoraproject.org/resultsdb/frontend , right now. -- 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
Re: Fwd: [mirall] plasma client try3
Joseph Marrero wrote:
From: Joseph Marrero jmarr...@gmail.com
Date: Wed, Mar 6, 2013 at 11:40 PM
Subject: Re: [mirall] plasma client try3
To: Kevin Fenzi ke...@scrye.com
I am preparing the package for upstream merge between mirall and
owncloud-plasma-client
Looks like the root cause is more likely this snippet from
src/CMakeLists.txt:
install(TARGETS owncloudsync
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib
BUNDLE DESTINATION library
)
contrast this with similar (and imo better) snippet about mirall:
install(TARGETS mirall
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
)
See how the former hard-codes relative paths bin and lib? (not good, from a
packaging-perspective anyway)
-- rex
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Wed, Mar 6, 2013 at 7:15 PM, Adam Williamson awill...@redhat.com wrote: On 06/03/13 04:39 AM, Dan Mashal wrote: Took libindicator too. Is this deprecated upstream? No, there are commits right up to late Feb in launchpad. But then I don't immediately see that you'd want it for MATE purposes (or really any other Fedora purposes); it's a Unity thing. I packaged and used to own it for my aborted plan to try and package Unity, and it's orphaned because I don't want it any more. I don't think it has any dependencies in Fedora, and I think it's pretty useless if you're not running Unity. bamf is in a similar position, but at least _something_ - gnome-pie, whatever that is - requires it. So it might actually be more useful for someone to pick that 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 I don't know what gnome-pie / bamf are and what they do. Gnome maintainers, you may want to take those? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Thu, Mar 7, 2013 at 4:15 AM, Adam Williamson awill...@redhat.com wrote: On 06/03/13 04:39 AM, Dan Mashal wrote: Took libindicator too. Is this deprecated upstream? No, there are commits right up to late Feb in launchpad. But then I don't immediately see that you'd want it for MATE purposes (or really any other Fedora purposes); it's a Unity thing. I packaged and used to own it for my aborted plan to try and package Unity, and it's orphaned because I don't want it any more. I don't think it has any dependencies in Fedora, and I think it's pretty useless if you're not running Unity. Then why not just retire it properly? I mean of course someone could step up to package unity in fedora but then, how likely and realistic is that? As a side note I was also wondering why so many important packages like hicolor-icon-theme were orphaned and I can't recall any announcement on -devel or -announce about that. Johannes bamf is in a similar position, but at least _something_ - gnome-pie, whatever that is - requires it. So it might actually be more useful for someone to pick that 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/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New list for QA development: qa-devel
On Thu, 7 Mar 2013 11:11:06 +0800 Christopher Meng cicku...@gmail.com wrote: A lot of wiki page should be updated. Thanks for the reminder - I haven't started on that yet. I'll make sure it gets done before we disable new posts on autoqa-devel@ Tim signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikey single-factor authentication disabled
I suppose I have to bite and ask why yubikey is regarded as single-factor? I guess it isn't something I know as well as something I have? Spot's poll is interesting - I see SecureID hard tokens leading the hard tokens featured (7am UTC Thursday) but how does an individual buy one? Clive -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikey single-factor authentication disabled
On 7 Mar 2013 07:09, Clive Hills discordia...@gmail.com wrote: I suppose I have to bite and ask why yubikey is regarded as single-factor? I guess it isn't something I know as well as something I have? Spot's poll is interesting - I see SecureID hard tokens leading the hard tokens featured (7am UTC Thursday) but how does an individual buy one? You don't. Smallest amount you can buy is 5 and that'll set you back $500 and still be useless as you need a dedicated infrastructure to use them. That infra is not what I would call open. There's also no cloud style hosted by the vendor. They're not open by any description IMO. At the cost they're a purely enterprise platform. Peter Clive -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikey single-factor authentication disabled
On Thu, 2013-03-07 at 07:09 +, Clive Hills wrote: Spot's poll is interesting - I see SecureID hard tokens leading the hard tokens featured (7am UTC Thursday) but how does an individual buy one? If you are referring to https://sparkslinux.wordpress.com/2013/03/06/poll-what-multi-factor-authentication-tokens-do-you-ownuse/ It's not spot but sparks who is the author. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikey single-factor authentication disabled
Thank you for the correction. My bad. Clearly I need another coffee before posting. Clive -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-File-pushd] 1.004 bump
commit cbbaa646b043e5e7f492361b74df1c8de7092933
Author: Petr Písař ppi...@redhat.com
Date: Wed Mar 6 09:59:27 2013 +0100
1.004 bump
.gitignore |1 +
.rpmlint |2 ++
perl-File-pushd.spec | 36 +---
sources |2 +-
4 files changed, 29 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index aaeade5..009a14a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ File-pushd-1.00.tar.gz
/File-pushd-1.001.tar.gz
/File-pushd-1.002.tar.gz
/File-pushd-1.003.tar.gz
+/File-pushd-1.004.tar.gz
diff --git a/.rpmlint b/.rpmlint
new file mode 100644
index 000..9a7e82a
--- /dev/null
+++ b/.rpmlint
@@ -0,0 +1,2 @@
+from Config import *
+addFilter(spelling-error .* (chdir|destructor));
diff --git a/perl-File-pushd.spec b/perl-File-pushd.spec
index db81e50..c7e13fd 100644
--- a/perl-File-pushd.spec
+++ b/perl-File-pushd.spec
@@ -1,30 +1,41 @@
Name: perl-File-pushd
-Version:1.003
-Release:2%{?dist}
+Version:1.004
+Release:1%{?dist}
Summary:Change directory temporarily for a limited scope
License:ASL 2.0
Group: Development/Libraries
URL:http://search.cpan.org/dist/File-pushd/
Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/File-pushd-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+# Run-time:
BuildRequires: perl(Carp)
BuildRequires: perl(Cwd)
BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Path)
BuildRequires: perl(File::Spec)
-BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(File::Temp)
+BuildRequires: perl(overload)
+# Tests:
+BuildRequires: perl(lib)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Spec::Functions)
+BuildRequires: perl(List::Util)
BuildRequires: perl(Test::More)
+# Optional tests:
+BuildRequires: perl(Test::Script) = 1.05
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
-File::pushd does a temporary chdir that is easily and automatically
-reverted, similar to pushd in some Unix command shells. It works by
-creating an object that caches the original working directory. When the
-object is destroyed, the destructor calls chdir to revert to the original
-working directory. By storing the object in a lexical variable with a
-limited scope, this happens automatically at the end of the scope.
+File::pushd does a temporary chdir that is easily and automatically reverted,
+similar to pushd in some Unix command shells. It works by creating an object
+that caches the original working directory. When the object is destroyed, the
+destructor calls chdir to revert to the original working directory. By storing
+the object in a lexical variable with a limited scope, this happens
+automatically at the end of the scope.
%prep
%setup -q -n File-pushd-%{version}
@@ -42,11 +53,14 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} \;
make test
%files
-%doc Changes LICENSE README Todo
+%doc Changes CONTRIBUTING LICENSE README Todo
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Wed Mar 06 2013 Petr Pisar ppi...@redhat.com - 1.004-1
+- 1.004 bump
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.003-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 6860de1..0f38e4b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-32c1c7d13e391f68fcd8ea63a5ad8fe7 File-pushd-1.003.tar.gz
+2c10f984845444b58a9f999dbf30f8f4 File-pushd-1.004.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
[Bug 918426] perl-File-pushd-1.004 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=918426 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-File-pushd-1.004-1.fc1 ||9 Resolution|--- |RAWHIDE Last Closed||2013-03-06 04:12:31 -- 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=X0WkVY7eSza=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-Math-Clipper
perl-Math-Clipper has broken dependencies in the rawhide tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 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
[perl-NOCpulse-Utils] Rebase to perl-NOCpulse-Utils-1.14.12-1.fc18 in rawhide.
commit 8f42af88a6012f4b2333020e50cbd9b32a9c0c61
Author: Miroslav Suchý msu...@redhat.com
Date: Wed Mar 6 16:29:06 2013 +0100
Rebase to perl-NOCpulse-Utils-1.14.12-1.fc18 in rawhide.
.gitignore |1 +
perl-NOCpulse-Utils.spec | 44 ++--
sources |2 +-
3 files changed, 8 insertions(+), 39 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 044cf56..0cd34fa 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
perl-NOCpulse-Utils-1.14.11.tar.gz
+/perl-NOCpulse-Utils-1.14.12.tar.gz
diff --git a/perl-NOCpulse-Utils.spec b/perl-NOCpulse-Utils.spec
index a031da2..d7abda6 100644
--- a/perl-NOCpulse-Utils.spec
+++ b/perl-NOCpulse-Utils.spec
@@ -1,6 +1,6 @@
Name: perl-NOCpulse-Utils
-Version: 1.14.11
-Release: 13%{?dist}
+Version: 1.14.12
+Release: 1%{?dist}
Summary: NOCpulse utility packages
URL: https://fedorahosted.org/spacewalk
Source0:
https://fedorahosted.org/releases/s/p/spacewalk/%{name}-%{version}.tar.gz
@@ -9,6 +9,7 @@ Group:Development/Libraries
License: GPLv2
Buildroot:%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildRequires: /usr/bin/pod2man
%description
NOCpulse provides application, network, systems and transaction monitoring,
@@ -36,7 +37,6 @@ mkdir -p $RPM_BUILD_ROOT%{_mandir}/man3/
/usr/bin/pod2man $RPM_BUILD_ROOT%{perl_vendorlib}/NOCpulse/Module.pm |gzip
$RPM_BUILD_ROOT%{_mandir}/man3/NOCpulse::Module.3pm.gz
%files
-%defattr(-,root,root)
%dir %{perl_vendorlib}/NOCpulse
%{perl_vendorlib}/NOCpulse/*
%{_mandir}/man3/*
@@ -45,41 +45,9 @@ mkdir -p $RPM_BUILD_ROOT%{_mandir}/man3/
rm -rf $RPM_BUILD_ROOT
%changelog
-* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.14.11-13
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
-
-* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.14.11-12
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
-
-* Fri Jun 08 2012 Petr Pisar ppi...@redhat.com - 1.14.11-11
-- Perl 5.16 rebuild
-
-* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.14.11-10
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
-
-* Fri Jun 17 2011 Marcela Mašláňová mmasl...@redhat.com - 1.14.11-9
-- Perl mass rebuild
-
-* Fri Jun 10 2011 Marcela Mašláňová mmasl...@redhat.com - 1.14.11-8
-- Perl 5.14 mass rebuild
-
-* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.14.11-7
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
-
-* Tue Dec 21 2010 Marcela Maslanova mmasl...@redhat.com - 1.14.11-6
-- 661697 rebuild for fixing problems with vendorach/lib
-
-* Tue May 04 2010 Marcela Maslanova mmasl...@redhat.com - 1.14.11-5
-- Mass rebuild with perl-5.12.0
-
-* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 1.14.11-4
-- rebuild against perl 5.10.1
-
-* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.14.11-3
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
-
-* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.14.11-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+* Mon Feb 18 2013 Miroslav Suchý msu...@redhat.com 1.14.12-1
+- Buildrequire pod2man
+- %%defattr is not needed since rpm 4.4
* Wed Jan 7 2009 Milan Zazrivec 1.14.11-1
- include documentation fixes
diff --git a/sources b/sources
index c9ff2aa..889e2bb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fc962eb4a529f467911494d9d508512f perl-NOCpulse-Utils-1.14.11.tar.gz
+c454ff9f71e9a1d0aff2aa6be00c384b perl-NOCpulse-Utils-1.14.12.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-NOCpulse-Utils] Created tag perl-NOCpulse-Utils-1.14.12-1.fc19
The unsigned tag 'perl-NOCpulse-Utils-1.14.12-1.fc19' was created. Tagger: Miroslav Suchý msu...@redhat.com Date: Wed Mar 6 16:29:12 2013 +0100 Buildrequire pod2man - %defattr is not needed since rpm 4.4 Changes since the last tag 'perl-NOCpulse-Utils-1_14_11-5_fc14': Dennis Gilmore (4): - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild Fedora Release Engineering (1): dist-git conversion Marcela Mašláňová (3): - 661697 rebuild for fixing problems with vendorach/lib Perl 5.14 mass rebuild Perl mass rebuild Miroslav Suchý (1): Rebase to perl-NOCpulse-Utils-1.14.12-1.fc18 in rawhide. Petr Písař (1): Perl 5.16 rebuild -- 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-CPANPLUS (un)retirement
Package perl-CPANPLUS in Fedora devel has been unretired by limb and is now orphan. To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-CPANPLUS -- 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 re-engine-RE2-0.11.tar.gz uploaded to lookaside cache by bochecha
A file has been added to the lookaside cache for perl-re-engine-RE2: 04861f52339ee55e7b88d29308f26832 re-engine-RE2-0.11.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-re-engine-RE2: 1/8] Initial setup of the pre-review repo
commit f26148bd4e870e08ee3eedd3353fe514562c9a49 Author: Mathieu Bridon boche...@fedoraproject.org Date: Wed Feb 20 11:54:07 2013 +0800 Initial setup of the pre-review repo 0 files changed, 0 insertions(+), 0 deletions(-) --- diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..e69de29 diff --git a/sources b/sources new file mode 100644 index 000..e69de29 -- 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-re-engine-RE2: 3/8] Remove incorrect executable bits
commit 5a40846eb0c68a9a7a15ac9d8c6939f266c506d6
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Thu Feb 21 11:09:32 2013 +0800
Remove incorrect executable bits
perl-re-engine-RE2.spec |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
---
diff --git a/perl-re-engine-RE2.spec b/perl-re-engine-RE2.spec
index 1132de5..2231bae 100644
--- a/perl-re-engine-RE2.spec
+++ b/perl-re-engine-RE2.spec
@@ -26,6 +26,9 @@ This module replaces perl's regex engine in a given lexical
scope with RE2.
%prep
%setup -q -n re-engine-RE2-%{version}
+# Remove incorrect executable bits
+chmod -x lib/re/engine/RE2.pm
+
%patch0 -p1
@@ -55,5 +58,7 @@ make test
%changelog
+- Remove incorrect executable bits.
+
* Wed Feb 20 2013 Mathieu Bridon boche...@fedoraproject.org - 0.11-1
- Initial package, with help from cpanspec.
--
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-re-engine-RE2: 4/8] Add a missing build requirement
commit e331d5243133855cc5c5f96cc82c86b4078e2fdc Author: Mathieu Bridon boche...@fedoraproject.org Date: Thu Feb 21 11:09:49 2013 +0800 Add a missing build requirement perl-re-engine-RE2.spec |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/perl-re-engine-RE2.spec b/perl-re-engine-RE2.spec index 2231bae..3122c44 100644 --- a/perl-re-engine-RE2.spec +++ b/perl-re-engine-RE2.spec @@ -12,6 +12,7 @@ Patch0: re-engine-RE2-0.11-Unbundle-re2.patch BuildRequires:perl(ExtUtils::CppGuess) BuildRequires:perl(ExtUtils::MakeMaker) +BuildRequires:perl(XSLoader) BuildRequires:perl(Test::More) BuildRequires:re2-devel @@ -59,6 +60,7 @@ make test %changelog - Remove incorrect executable bits. +- Add a missing build requirement. * Wed Feb 20 2013 Mathieu Bridon boche...@fedoraproject.org - 0.11-1 - Initial package, with help from cpanspec. -- 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-re-engine-RE2: 5/8] Bump and resubmit to the review
commit ecf96b08e15db6266760e5b26e433a7072051741
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Thu Feb 21 12:44:08 2013 +0800
Bump and resubmit to the review
https://bugzilla.redhat.com/show_bug.cgi?id=913004#c1
perl-re-engine-RE2.spec |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/perl-re-engine-RE2.spec b/perl-re-engine-RE2.spec
index 3122c44..8b6b344 100644
--- a/perl-re-engine-RE2.spec
+++ b/perl-re-engine-RE2.spec
@@ -1,7 +1,7 @@
Name: perl-re-engine-RE2
Summary: RE2 regex engine
Version: 0.11
-Release: 1%{?dist}
+Release: 2%{?dist}
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/re-engine-RE2/
Source0:
http://www.cpan.org/authors/id/D/DG/DGL/re-engine-RE2-%{version}.tar.gz
@@ -59,6 +59,7 @@ make test
%changelog
+* Thu Feb 21 2013 Mathieu Bridon boche...@fedoraproject.org - 0.11-2
- Remove incorrect executable bits.
- Add a missing build requirement.
--
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-re-engine-RE2: 7/8] The package was approved in Fedora
commit 624067cf6934920f35cee06158b64e7c74f1af91 Merge: ba4e05a 4711d70 Author: Mathieu Bridon boche...@fedoraproject.org Date: Thu Mar 7 14:03:42 2013 +0800 The package was approved in Fedora perl-re-engine-RE2.spec | 73 ++ re-engine-RE2-0.11-Unbundle-re2.patch | 167 + 2 files changed, 240 insertions(+), 0 deletions(-) --- -- 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-re-engine-RE2: 8/8] Upload the sources
commit fde5a3123f5b818654646cba7953976c1d4a0e1b Author: Mathieu Bridon boche...@fedoraproject.org Date: Thu Mar 7 14:04:43 2013 +0800 Upload the sources .gitignore |1 + sources|1 + 2 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/.gitignore b/.gitignore index e69de29..e672251 100644 --- a/.gitignore +++ b/.gitignore @@ -0,0 +1 @@ +/re-engine-RE2-0.11.tar.gz diff --git a/sources b/sources index e69de29..0ed5f2a 100644 --- a/sources +++ b/sources @@ -0,0 +1 @@ +04861f52339ee55e7b88d29308f26832 re-engine-RE2-0.11.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
File ParseUtil-Domain-2.22.tar.gz uploaded to lookaside cache by bochecha
A file has been added to the lookaside cache for perl-ParseUtil-Domain: 653c68c05a16b7acfe15ce2e295c634f ParseUtil-Domain-2.22.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-ParseUtil-Domain] (11 commits) ...Upload the sources
Summary of changes:
16baba2... Initial setup of the pre-review repo
6cdd695... Initial package for Fedora
9211b64... Replace usage of the %{__perl} macro by the plain perl comm
2cf22a9... Add missing build requirements
7831d29... Remove incorrect executable bits
d11b31b... New submission for Fedora
4e473b3... Change tlds to TLDs in the description
d73f035... Add missing build requirements
2cbc408... Bump for new submission
d6cbacb... The package was approved
0abf1ce... Upload the sources
--
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-ParseUtil-Domain: 1/11] Initial setup of the pre-review repo
commit 16baba2f29b2d9a74449eaebaf1975fb9607a769 Author: Mathieu Bridon boche...@fedoraproject.org Date: Wed Jan 2 08:12:29 2013 +0800 Initial setup of the pre-review repo 0 files changed, 0 insertions(+), 0 deletions(-) --- diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..e69de29 diff --git a/sources b/sources new file mode 100644 index 000..e69de29 -- 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-ParseUtil-Domain: 2/11] Initial package for Fedora
commit 6cdd69532dfa475969b7c6060ced5cef7c959a14
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Mon Jan 7 14:10:14 2013 +0800
Initial package for Fedora
This was submitted for review on Mon Jan 07 2013:
https://bugzilla.redhat.com/show_bug.cgi?id=892433#c0
perl-ParseUtil-Domain.spec | 72
1 files changed, 72 insertions(+), 0 deletions(-)
---
diff --git a/perl-ParseUtil-Domain.spec b/perl-ParseUtil-Domain.spec
new file mode 100644
index 000..318f362
--- /dev/null
+++ b/perl-ParseUtil-Domain.spec
@@ -0,0 +1,72 @@
+Name: perl-ParseUtil-Domain
+Summary:Utility for parsing a domain name into its components
+Version:2.22
+Release:1%{?dist}
+
+# - ParseUtil::Domain is GPL+ or Artistic (the Perl license)
+# - data/effective_tld_names.txt is MPLv2.0
+# - ParseUtil::Domain::ConfigData is automatically generated during the build,
+# based on the contents of data/effective_tld_names.txt
+License:(GPL+ or Artistic) and MPLv2.0
+
+URL:http://search.cpan.org/dist/ParseUtil-Domain/
+Source0:
http://www.cpan.org/authors/id/H/HE/HEYTRAV/ParseUtil-Domain-%{version}.tar.gz
+
+BuildArch: noarch
+
+BuildRequires: perl(Module::Build)
+BuildRequires: perl(namespace::autoclean)
+BuildRequires: perl(Net::IDN::Encode) = 2.003
+BuildRequires: perl(Net::IDN::Nameprep) = 1.101
+BuildRequires: perl(Perl6::Export::Attrs)
+BuildRequires: perl(Perl::Critic)
+BuildRequires: perl(Regexp::Assemble::Compressed)
+BuildRequires: perl(Smart::Comments)
+BuildRequires: perl(Test::Class)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::Deep)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Perl::Critic)
+BuildRequires: perl(Test::Routine)
+BuildRequires: perl(Unicode::CharName) = 1.07
+BuildRequires: perl(YAML)
+
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+A tool for parsing domain names. This module makes use of the data provided
+by the Public Suffix List (http://publicsuffix.org/list/) to parse tlds.
+
+
+%prep
+%setup -q -n ParseUtil-Domain-%{version}
+
+
+%build
+%{__perl} Build.PL installdirs=vendor
+./Build
+
+
+%install
+./Build install destdir=%{buildroot} create_packlist=0
+
+%{_fixperms} %{buildroot}/*
+
+
+%check
+./Build test
+
+
+%files
+%doc data/effective_tld_names.txt README
+%{_bindir}/punyconvert
+%{_mandir}/man1/punyconvert.1*
+%{_mandir}/man3/ParseUtil::Domain*3pm*
+%{perl_vendorlib}/ParseUtil*
+
+
+%changelog
+* Wed Jan 02 2013 Mathieu Bridon boche...@fedoraproject.org - 2.22-1
+- Initial package for Fedora, with help from cpanspec.
--
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-ParseUtil-Domain: 3/11] Replace usage of the %{__perl} macro by the plain perl command
commit 9211b648a6b2cd18f7c3cf6311044713f03c9aac
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Fri Jan 25 13:05:01 2013 +0800
Replace usage of the %{__perl} macro by the plain perl command
perl-ParseUtil-Domain.spec |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
---
diff --git a/perl-ParseUtil-Domain.spec b/perl-ParseUtil-Domain.spec
index 318f362..13dcd39 100644
--- a/perl-ParseUtil-Domain.spec
+++ b/perl-ParseUtil-Domain.spec
@@ -31,7 +31,7 @@ BuildRequires: perl(Test::Routine)
BuildRequires: perl(Unicode::CharName) = 1.07
BuildRequires: perl(YAML)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%{?perl_default_filter}
@@ -45,7 +45,7 @@ by the Public Suffix List (http://publicsuffix.org/list/) to
parse tlds.
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL installdirs=vendor
./Build
@@ -68,5 +68,7 @@ by the Public Suffix List (http://publicsuffix.org/list/) to
parse tlds.
%changelog
+- Replace usage of the %%{__perl} macro by the plain perl command.
+
* Wed Jan 02 2013 Mathieu Bridon boche...@fedoraproject.org - 2.22-1
- Initial package for Fedora, with help from cpanspec.
--
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-ParseUtil-Domain: 4/11] Add missing build requirements
commit 2cf22a94bffdeb844bad911210af494b14f58847
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Fri Jan 25 13:25:32 2013 +0800
Add missing build requirements
perl-ParseUtil-Domain.spec |4
1 files changed, 4 insertions(+), 0 deletions(-)
---
diff --git a/perl-ParseUtil-Domain.spec b/perl-ParseUtil-Domain.spec
index 13dcd39..6b61ce3 100644
--- a/perl-ParseUtil-Domain.spec
+++ b/perl-ParseUtil-Domain.spec
@@ -14,10 +14,13 @@ Source0:
http://www.cpan.org/authors/id/H/HE/HEYTRAV/ParseUtil-Domain-%{v
BuildArch: noarch
+BuildRequires: perl(Carp)
+BuildRequires: perl(List::MoreUtils)
BuildRequires: perl(Module::Build)
BuildRequires: perl(namespace::autoclean)
BuildRequires: perl(Net::IDN::Encode) = 2.003
BuildRequires: perl(Net::IDN::Nameprep) = 1.101
+BuildRequires: perl(Net::IDN::Punycode)
BuildRequires: perl(Perl6::Export::Attrs)
BuildRequires: perl(Perl::Critic)
BuildRequires: perl(Regexp::Assemble::Compressed)
@@ -69,6 +72,7 @@ perl Build.PL installdirs=vendor
%changelog
- Replace usage of the %%{__perl} macro by the plain perl command.
+- Add missing build requirements.
* Wed Jan 02 2013 Mathieu Bridon boche...@fedoraproject.org - 2.22-1
- Initial package for Fedora, with help from cpanspec.
--
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-ParseUtil-Domain: 5/11] Remove incorrect executable bits
commit 7831d29f189018887675685b8fd5bf75dd6a4c99
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Fri Jan 25 13:25:46 2013 +0800
Remove incorrect executable bits
perl-ParseUtil-Domain.spec |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
---
diff --git a/perl-ParseUtil-Domain.spec b/perl-ParseUtil-Domain.spec
index 6b61ce3..c737ff9 100644
--- a/perl-ParseUtil-Domain.spec
+++ b/perl-ParseUtil-Domain.spec
@@ -46,6 +46,10 @@ by the Public Suffix List (http://publicsuffix.org/list/) to
parse tlds.
%prep
%setup -q -n ParseUtil-Domain-%{version}
+# Remove incorrect executable bits
+chmod -x lib/ParseUtil/Domain.pm \
+ README \
+ data/effective_tld_names.txt
%build
perl Build.PL installdirs=vendor
@@ -73,6 +77,7 @@ perl Build.PL installdirs=vendor
%changelog
- Replace usage of the %%{__perl} macro by the plain perl command.
- Add missing build requirements.
+- Remove incorrect executable bits.
* Wed Jan 02 2013 Mathieu Bridon boche...@fedoraproject.org - 2.22-1
- Initial package for Fedora, with help from cpanspec.
--
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-ParseUtil-Domain: 6/11] New submission for Fedora
commit d11b31b8407ea3389d2f35a008829f6236a2ef59
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Fri Jan 25 13:37:38 2013 +0800
New submission for Fedora
This was submitted on Fri Jan 25 2013:
https://bugzilla.redhat.com/show_bug.cgi?id=892433#c2
perl-ParseUtil-Domain.spec |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/perl-ParseUtil-Domain.spec b/perl-ParseUtil-Domain.spec
index c737ff9..5367427 100644
--- a/perl-ParseUtil-Domain.spec
+++ b/perl-ParseUtil-Domain.spec
@@ -1,7 +1,7 @@
Name: perl-ParseUtil-Domain
Summary:Utility for parsing a domain name into its components
Version:2.22
-Release:1%{?dist}
+Release:2%{?dist}
# - ParseUtil::Domain is GPL+ or Artistic (the Perl license)
# - data/effective_tld_names.txt is MPLv2.0
@@ -75,6 +75,7 @@ perl Build.PL installdirs=vendor
%changelog
+* Fri Jan 25 2013 Mathieu Bridon boche...@fedoraproject.org - 2.22-2
- Replace usage of the %%{__perl} macro by the plain perl command.
- Add missing build requirements.
- Remove incorrect executable bits.
--
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
