Re: Packages that will be orphaned
Hi. May I take the apache-commons-collections ? Thanks :] BR, Jaromir. -- Red Hat Czech, s.r.o. Software Engineer / BaseOS Email: jca...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic IC: 27690016 - Original Message - From: "Toshio Kuratomi" To: "Development discussions related to Fedora" Sent: Tuesday, June 21, 2011 2:02:01 AM Subject: Re: Packages that will be orphaned On Mon, Jun 20, 2011 at 08:04:46PM +0200, Jarosław Górny wrote: > Oh, dear, I've missed the deadline. I've signed the FPCA now. > I received a notice: > "You have successfully completed the FPCA. You are now in the > 'cla_fpca' group" > > Hope it's not too late... > Not at all. Updated lists are now available on http://toshio.fedorapeople.org/fpca/ adanaxisgpl adf-accanthis-fonts adf-tribun-fonts apache-commons-collections apanov-edrip-fonts apanov-heuristica-fonts atop auto-destdir bibletime bitstream-vera-fonts brandy buffer camcardsync cdo ciso clex cmospwd CodeAnalyst-gui comoonics-base-py contextkit cronolog ctapi-cyberjack cwrite db4o dbh dejavu-fonts demorse drbd ecolier-court-fonts edsadmin elfinfo EmfEngine espeak fcitx feh fig2sxd flite fontpackages gdeskcal gdesklets-goodweather gdesklets-quote-of-the-day gdm gfs-ambrosia-fonts gfs-artemisia-fonts gfs-baskerville-fonts gfs-bodoni-classic-fonts gfs-bodoni-fonts gfs-complutum-fonts gfs-decker-fonts gfs-didot-classic-fonts gfs-didot-fonts gfs-eustace-fonts gfs-fleischman-fonts gfs-garaldus-fonts gfs-gazis-fonts gfs-goschen-fonts gfs-ignacio-fonts gfs-jackson-fonts gfs-neohellenic-fonts gfs-nicefore-fonts gfs-olga-fonts gfs-philostratos-fonts gfs-porson-fonts gfs-pyrsos-fonts gfs-solomos-fonts gfs-theokritos-fonts ghost-diagrams gnome-globalmenu gnome-rdp gnome-screensaver gnome-themes-extras granule greadelf griv gtkparasite gtranslator gts gurlchecker gwaei halibut harminv healpy HippoDraw imagej imgtarget initng initng-conf-gtk initng-ifiles itpp jomolhari-fonts kanjistrokeorders-fonts kbibtex kde-plasma-ihatethecashew kde-plasma-translatoid kdetv kgtk klibido knutclient krusader leafpad libaccounts-glib libaccounts-qt libassa libax25 libcgroup libcmpiutil libctl libdwarf libglfw libibverbs libkdcraw liblicense libmatheval libmlx4 libmthca liborigin2 libqttracker libvirt-cim libvirt-qpid libwps LinLog linpsk linuxdcpp madwimax mod_auth_pam mod_dnssd moin-latex monotorrent moto4lin mrepo multiget mumbles muParser mx nabi ncview netcdf netsniff-ng notification-daemon-engine-slider ocfs2-tools oflb-riordonfancy-fonts olpcsound osiv paratype-pt-sans-fonts pcmanx-gtk2 perl-Config-Simple perl-Font-TTF perl-Ham-Reference-QRZ perl-Makefile-DOM perl-Net-SMTP-SSL pgRouting phoronix-test-suite photoprint photoprint-borders picocom pisg polipo presto procbench proxychains purple-plugin_pack python-Chaco python-Enable python-mechanoid python-pip python-polib python-pydns python-pyspf python-rabbyt python-tilecache python-TraitsBackendWX python-werkzeug python-zc-lockfile python-zdaemon python-zope-event python-zope-testing pywebkitgtk pyxmms qjson qoauth qps qt4-qsa qterm QTeXEngine qtiplot quazip qwit qwt qwt-doc rubygem-heroku rubygem-mail rubygem-mustache rubygem-railties rubygem-tzinfo scantailor scidavis scitools scrip secstate seedit senamirmir-washra-fonts sil-andika-fonts sil-charis-compact-fonts sil-charis-fonts sirius smb4k SOAPpy sound-theme-freedesktop spyder ss5 stix-fonts stp straw sx tcptrack tenr-de-styles-pkg tetrinetx tex-zfuzz tibetan-machine-uni-fonts tinycdb transifex userspace-rcu vidalia vifm webattery whowatch wifiroamd xcowsay xdx xerces-c xgridfit xinha xmlcopyeditor xmms xmms-alarm xqilla xvkbd yanone-kaffeesatz-fonts zenon zvbi -Toshio -- 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
Heads up: procps-ng 3.3.2 introduction (can break more than 30 packages)
Hello, folks. I'm going to replace our current (legacy) procps tools with new generation procps tools (procps-ng) in next 2 weeks. The procps-ng tools are still pretty compatible with the old ones, but anyway, this change might have a negative impact on the following packages listed by the repoquery and I recommed you to stay tuned and check if they still work properly once the procps-ng-3.3.2 appears in the repo. autofs-1:5.0.6-11.fc18.x86_64 backup-light-0:0.4-6.fc17.noarch bwm-ng-0:0.6-8.fc17.x86_64 cloud-init-0:0.6.2-0.8.bzr457.fc17.noarch cone-0:0.84-4.fc17.src cups-pdf-0:2.6.1-1.fc17.x86_64 egd-0:0.9-7.fc17.noarch environment-modules-0:3.2.9c-2.fc17.x86_64 gearmand-0:0.23-2.fc17.x86_64 hail-0:0.8-0.7.gf9c5b967.fc17.src initscripts-0:9.34-3.fc17.x86_64 jed-0:0.99.19-4.fc17.src ksh-0:20120214-1.fc18.src libguestfs-1:1.17.8-1.fc18.src libguestfs-1:1.17.8-1.fc18.i686 libguestfs-1:1.17.8-1.fc18.x86_64 libqb-0:0.10.1-1.fc18.src make-1:3.82-9.fc17.src munin-node-0:1.4.6-7.fc17.noarch mysql-0:5.5.20-1.fc17.src net-snmp-1:5.7.1-4.fc17.src olpc-netutils-0:0.8.1-2.fc17.noarch parprouted-0:0.70-7.fc17.x86_64 parrot-0:3.6.0-4.fc17.1.src perl-4:5.14.2-211.fc17.src perl-IO-Socket-SSL-0:1.54-1.fc17.src perl-Proc-PID-File-0:1.27-6.fc17.noarch pcp-0:3.5.11-2.fc17.src readahead-1:1.5.7-4.fc17.x86_64 redhat-lsb-0:4.0-11.fc17.i686 redhat-lsb-0:4.0-11.fc17.x86_64 resource-agents-0:3.9.2-2.fc17.1.x86_64 rkhunter-0:1.3.8-14.fc17.noarch ruby-0:1.9.3.0-7.fc17.src rusers-0:0.17-67.fc17.src system-config-users-0:1.2.113-1.fc18.noarch tabled-0:0.5.1-0.5.g33595340.fc18.src tog-pegasus-2:2.11.1-4.fc17.src tomcat-0:7.0.25-4.fc18.noarch tomcat6-0:6.0.32-20.fc17.noarch wallpapoz-0:0.6.1-2.fc17.noarch Thanks, Jaromir. -- Jaromir Capik Red Hat Czech, s.r.o. Software Engineer / BaseOS Email: jca...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic IC: 27690016 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: procps-ng 3.3.2 introduction (can break more than 30 packages)
Hello, folks. I'm going to replace our current (legacy) procps tools with new generation procps tools (procps-ng) in next 2 weeks. The procps-ng tools are still pretty compatible with the old ones, but anyway, this change might have a negative impact on the following packages listed by the repoquery and I recommed you to stay tuned and check if they still work properly once the procps-ng-3.3.2 appears in the repo. autofs-1:5.0.6-11.fc18.x86_64 backup-light-0:0.4-6.fc17.noarch bwm-ng-0:0.6-8.fc17.x86_64 cloud-init-0:0.6.2-0.8.bzr457.fc17.noarch cone-0:0.84-4.fc17.src cups-pdf-0:2.6.1-1.fc17.x86_64 egd-0:0.9-7.fc17.noarch environment-modules-0:3.2.9c-2.fc17.x86_64 gearmand-0:0.23-2.fc17.x86_64 hail-0:0.8-0.7.gf9c5b967.fc17.src initscripts-0:9.34-3.fc17.x86_64 jed-0:0.99.19-4.fc17.src ksh-0:20120214-1.fc18.src libguestfs-1:1.17.8-1.fc18.src libguestfs-1:1.17.8-1.fc18.i686 libguestfs-1:1.17.8-1.fc18.x86_64 libqb-0:0.10.1-1.fc18.src make-1:3.82-9.fc17.src munin-node-0:1.4.6-7.fc17.noarch mysql-0:5.5.20-1.fc17.src net-snmp-1:5.7.1-4.fc17.src olpc-netutils-0:0.8.1-2.fc17.noarch parprouted-0:0.70-7.fc17.x86_64 parrot-0:3.6.0-4.fc17.1.src perl-4:5.14.2-211.fc17.src perl-IO-Socket-SSL-0:1.54-1.fc17.src perl-Proc-PID-File-0:1.27-6.fc17.noarch pcp-0:3.5.11-2.fc17.src readahead-1:1.5.7-4.fc17.x86_64 redhat-lsb-0:4.0-11.fc17.i686 redhat-lsb-0:4.0-11.fc17.x86_64 resource-agents-0:3.9.2-2.fc17.1.x86_64 rkhunter-0:1.3.8-14.fc17.noarch ruby-0:1.9.3.0-7.fc17.src rusers-0:0.17-67.fc17.src system-config-users-0:1.2.113-1.fc18.noarch tabled-0:0.5.1-0.5.g33595340.fc18.src tog-pegasus-2:2.11.1-4.fc17.src tomcat-0:7.0.25-4.fc18.noarch tomcat6-0:6.0.32-20.fc17.noarch wallpapoz-0:0.6.1-2.fc17.noarch Thanks, Jaromir. -- Jaromir Capik Red Hat Czech, s.r.o. Software Engineer / BaseOS Email: jca...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic IC: 27690016 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive maintainer: Jaromír Cápík
Dear Luya. I consider this to be one of the most unfair manner I've ever seen in my life. You haven't tried to contact me directly in any way even when it is not difficult at all. I'm available on the #fedora-devel IRC channel and you could send me a direct e-mail message as well. Instead of that you spam the devel list. Please, read the policy for non-responsive package maintainers before doing such thing again. I maintain 10x more components than you do and also work on fedora affiliated projects that need my focus right now. Even of that I managed to decrease the high number of opened bugs to 80% during the last year. Not all of them can get my attention immediately and if you need something urgently, then ping me and try to ask me for help instead of playing this theatre. I'd be happy to switch to a different task, if possible. Thanks for your understanding. -- Jaromir Capik Red Hat Czech, s.r.o. Software Engineer / Secondary Arch Email: jca...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic IC: 27690016 > > wrote: > >> Upstream version of phatch is available and also a patch provided on > >> https://bugzilla.redhat.com/show_bug.cgi?id=1192867 but the assignee is > >> unresponsive. > > The patch has been attached less than a week ago ... > I will wait for the response in the next week then. > > -- > Luya Tshimbalanga > Graphic & Web Designer > E: l...@fedoraproject.org > W: http://www.coolest-storm.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora Bootstrap Project
Hello everyone. As some of you have already noticed, we recently started a Fedora affiliated project called "Fedora Bootstrap" that had a short kick-off meeting on the last Devconf, which took place in February. Unfortunately this announcement gained a delay due to the Fedora trademark licensing we had to resolve with RH Legal prior making the project public and some of you were probably startled and wondering what this is all about. So, let me introduce the project a bit. The project is targeted mainly at our ability to build Fedora from scratch, so that an introduction of new architectures is easier and shorter. However, it has more goals than that. We'd like to see it to become a cure for all bootstrap related issues you can imagine. We base our work on a set of bootstrap scripts initially designed approximately 4-5 years ago by DJ Delorie and maintained by a group of people (DJ Delorie, Mark Salter, Al Stone, Jon Masters, Aldy Hernandez, ...) since that. The current effort is targeted at creation of a testsuite we'd like to wrap the bootstrap scripts with. That way the scripts can still work as a standalone bootstrap solution whenever we need them and the periodic testsuite execution should keep the solution up-to-date and ready for immediate use. Thanks to Micah Denn + folks from the Fedora design team and thanks to Stephen Wadeley from the Content services we already have a project homepage with sane content, available at http://fedora-bootstrap.osop.rhcloud.com I'm also happy to announce, that we already have a working testsuite covering the first stage of bootstrap. You can find the results and build logs at http://fedora-bootstrap.osop.rhcloud.com/results/stage1/ When we started, the whole table was red except two green fields. Now it's mostly green, thanks to everyone who offered help. I'd also like to say "thank you" to everyone, who helped us to commit bootstrap recipes for the first stage to the Fedora git. That allows us to engage all component maintainers in the bootstrap process and do more automation stuff in the future. We're currently enhancing the testsuite to support stage2 testing and to generate presentable results. And again, I'd like to ask everyone for support with troubleshooting and pushing the stage2 recipes to the Fedora git. It's gonna be a lot of work and we cannot succeed without your help. I'm looking forward for your cooperation and in case of any questions, I'm here for you. Best regards, Jaromir Capik. -- Red Hat Czech, s.r.o. Software Engineer / Secondary Arch Email: jca...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic IC: 27690016 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Mono 4
Hello everone. > From: "Stephen Gallagher" > To: devel@lists.fedoraproject.org > Sent: Monday, May 4, 2015 2:32:46 PM > Subject: Re: F23 System Wide Change: Mono 4 > > So I don't really see any problem with bootstrapping it once with > monolite and then rebuilding it with itself, provided of course that > all of this happens in Rawhide well before Branch (the earlier the > better; ideally prior to the Mass Rebuild for F23). I tried to build the following SRPM in f23, f22 and f21. https://elsupergomez.fedorapeople.org/SRPMS/mono-3.4.0-2.fc20.src.rpm The build succeeds in f21, but FTBFS in f22 and f23. f21 build log: https://kojipkgs.fedoraproject.org//work/tasks/4478/9654478/build.log f22 build log: https://kojipkgs.fedoraproject.org//work/tasks/4337/9654337/build.log f23 build log: https://kojipkgs.fedoraproject.org//work/tasks/4188/9654188/build.log As the above files will disappear soon, I'm attaching the relevant part of the build log ... --- CC libmini_static_la-mini-posix.lo CXXLD libmini-static.la ar: `u' modifier ignored since `D' is the default (see `U') CC mono_boehm-main.o CCLD mono-boehm ./.libs/libmini-static.a(libmini_static_la-mini.o): In function `mono_get_jit_tls_offset': /builddir/build/BUILD/mono-3.4.0/mono/mini/mini.c:2637: undefined reference to `mono_jit_tls' /builddir/build/BUILD/mono-3.4.0/mono/mini/mini.c:2637: undefined reference to `mono_jit_tls' collect2: error: ld returned 1 exit status Makefile:1229: recipe for target 'mono-boehm' failed make[4]: Leaving directory '/builddir/build/BUILD/mono-3.4.0/mono/mini' make[4]: *** [mono-boehm] Error 1 make[3]: *** [all] Error 2 Makefile:1071: recipe for target 'all' failed make[3]: Leaving directory '/builddir/build/BUILD/mono-3.4.0/mono/mini' Makefile:374: recipe for target 'all-recursive' failed make[2]: Leaving directory '/builddir/build/BUILD/mono-3.4.0/mono' make[2]: *** [all-recursive] Error 1 Makefile:454: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/builddir/build/BUILD/mono-3.4.0' Makefile:381: recipe for target 'all' failed make: *** [all] Error 2 --- So, I guess the failure needs to be resolved first. Regards, Jaromir. -- Jaromir Capik Red Hat Czech, s.r.o. Software Engineer / Secondary Arch Email: jca...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic IC: 27690016 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
> > * #851 F18 Feature: procps-ng (next generation procps tools) - > > https://fedoraproject.org/wiki/Features/procps-ng (sgallagh, > > 18:11:34) > > * AGREED: Feature procps-ng is accepted (9 +1) (sgallagh, > > 18:14:47) > > Ahem. I think is is a really bad idea. "-ng" packages point to a huge > failure in the handling of the packages in question, and should not > be deemed a feature for Linux but a failure of Linux. Says who? You? It must be true then! It seems you really know, how to manipulate people, because the first thing I told to myself after reading this part of your message was : "What a melodic statement!" > Karel Zak has made clear that he is happy to merge procps into > util-linux (Karel is both upstream and downstream for u-l), and has > offered > to do the work. util-linux is the much better place for these > utilities, Is it? > so that common code, the development infrastructure, the build > system, > the documentation scheme, the release cycle and the maintainership > can > be shared. Why don't we create just one big package called for example "fedora-distribution" ? We could merge everything inside, because there must be a lot of common functions in all Fedora packages. Let's start doing it immediately, because it could take quite a long time! How much do you know about the procps and util-linux internals? Is it the knowledge or self-importance what makes you claim that? > There's really no point in all the bureaucracy for such a transition > if it just replaces one bad situation with another bad situation. There is. We had to change the name, since the former upstream is still somehow alive, but not enough to make us happy. And as there can't be two independent upstreams called procps, we decided to change the name to avoid conflicts. I strictly disagree with your opinion here. I don't consider procps-ng a replacement with another bad situation. I'm curious where you get enough courage to disparage effort and work of other people. That's the same like claiming that systemd is replacement of bad situation with even worse situation. How do you like it? > If you do a transition then do it right and merge procps into util-linux. Please, stop being always right, especially when you don't know much about projects you're trying to break. > We really don't need two packages with such overlapping > functionality. Is it overlapping? I believe it isn't. The tools would need to be completely redesigned and rewritten to possibly have at least a small set of common functions with util-linux. The question is if it is worthy enough for such a change. The current procps state is so bad, that we had to act really quickly and the unification in form of procps-ng was really inevitable. > Both of them had long phases in their history where > they > were slowly rotting along. The best way to fight that is having a > single > package from it so that this easier kept an eye on. Again. Why would it be easier? Because you said that? > They do very similar stuff Do they? You mean that tiny part touching the proc filesystem? Sorry, but I don't consider tools like fdisk or fdformat similar to tools like top or vmstat. Each of the tools has it's purpose and if anything inside is overlapping, then it's just a very small part and that could eventually be moved to a common library one day. But I believe there's more important work to be done here than playing with reordering the particular tools, moving them from package to package and creating just one huge monolithic rpm, that breaks the basic principles of modularity. > ,they need the same expertise from the hackers and maintainers > and > they should justbe one. > > Really, nobody needs transitions, renames and multiple independent > repos > for stuff that is very very similar in purpose and behaviour. Nobody? That means we're nobody for you, right? I remember such superior attitude from somewhere. Yes. It was one of my previous jobs where everybody was leaving the team because of one manager with similar attitude. > > I'd really like to see FESCO strongly ask the people behind procps-ng > to > help working in the integration of its tools into util-linux, to make > the basic set of tools more nicely integrated rather than continue to > grow apart! There's really no point in just rubberstamping everything > people suggest. FESCO should push people in the right direction, and > push them towards collaboration. FESCO, please steer fedora (and > Linux) > in the right direction here, that's your job! I'm happy that FESCO members are rational enough and are able to have their own point of view and opinions. > > Lennart Jaromir. > > -- > Lennart Poettering - Red Hat, Inc. > -- > 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: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
> From: "Matej Cepl" > To: devel@lists.fedoraproject.org > Sent: Tuesday, May 15, 2012 9:01:00 PM > Subject: Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's > FESCo Meeting (2012-05-14)) > > On 15.5.2012 14:03, Jaromir Capik wrote: > > There is. We had to change the name, since the former upstream > > is still somehow alive, but not enough to make us happy. > > Do we? I mean if the old procps package will be killed in Fedora > (which > I think it will be, right?) then what you describe could just happen > by > changing URL in Source0, cannot it? Ahoj Matěji. You're partially right. If we talk about the Fedora's package name, then it could remain untouched. But since the new upstream name had to be changed and I wanted others to know they're installing the -ng version, I changed the name to procps-ng. Moreover, I initially wanted to introduce both version concurrently and later I decided to drop procps completely because of unclarities in the resolution of virtual provides. Packaging guidelines also say that package names should match the upstream tarball or project name and the name change seemed to me as the clearest and best solution. Jaromír. > > Matěj > > -- > 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: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
> > You're partially right. > > If we talk about the Fedora's package name, then it could remain > > untouched. > > But since the new upstream name had to be changed and I wanted > > others to know > > they're installing the -ng version, I changed the name to > > procps-ng. > > Moreover, I initially wanted to introduce both version concurrently > > and later I decided to drop procps completely because of > > unclarities > > in the resolution of virtual provides. > > Right, having multiple procps-style packages installed at once is way > more > effort than it would ever be worth. Exactly. It would surely cause more troubles, than we can imagine at the moment. > > > Packaging guidelines also say that package names should match the > > upstream > > tarball or project name and the name change seemed to me as the > > clearest > > and best solution. > > Is it intended to ever name it back if the older version dies off? Good question. I know that a similar thing happened in case of util-linux. I'm personally not fully against that. But playing with names seems to me unnecessary unless the name conflicts with other projects and therefore renaming back is not absolutely necessary. > > Bill Jaromir. > -- > 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
Review Request: prboom-plus - Free enhanced DOOM engine
Hello everyone. I'm searching for volunteers willing to review the prboom-plus engine: https://bugzilla.redhat.com/show_bug.cgi?id=1026517 Anybody want to help with that? Thanks in advance. Regards, Jaromir. -- Jaromir Capik Red Hat Czech, s.r.o. Software Engineer / Secondary Arch Email: jca...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic IC: 27690016 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
