In need of C++ gurus
Hi, warzone2100 fails to build [1] and I have no idea how to fix that. Most of the errors are: main_sdl.cpp:79:13: error: expected unqualified-id before '__attribute__' static std::vector displaylist; // holds all our possible display lists ^ main_sdl.cpp:117:29: error: cannot convert 'bool' to '__vector(4) __bool int' in initialization static bool mouseInWindow = true; ^~~~ main_sdl.cpp:148:22: error: cannot convert 'bool' to '__vector(4) __bool int' in initialization bool GetTextEvents = false; ^ Could someone point me in the right direction? I've looked at [2], but that doesn't seem to help much in this case. [1] https://bugzilla.redhat.com/attachment.cgi?id=1254868 [2] https://gcc.gnu.org/gcc-7/porting_to.html Cheers, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: In need of C++ gurus
On Mon, 20 Feb 2017 09:15:46 +0100 Jan Synacek wrote: > Hi, > > warzone2100 fails to build [1] and I have no idea how to fix that. > Most of the errors are: it's a known problem on ppc64le, please search this lists archive, it was discussed recently (switching from --std=c++11 to --std=gnu++11 ??) Dan > > main_sdl.cpp:79:13: error: expected unqualified-id before > '__attribute__' static std::vector displaylist; // holds > all our possible display lists > ^ > main_sdl.cpp:117:29: error: cannot convert 'bool' to '__vector(4) > __bool int' in initialization > static bool mouseInWindow = true; > ^~~~ > main_sdl.cpp:148:22: error: cannot convert 'bool' to '__vector(4) > __bool int' in initialization > bool GetTextEvents = false; > ^ > > Could someone point me in the right direction? I've looked at [2], but > that doesn't seem to help much in this case. > > [1] https://bugzilla.redhat.com/attachment.cgi?id=1254868 > [2] https://gcc.gnu.org/gcc-7/porting_to.html > > Cheers, > -- > Jan Synacek > Software Engineer, Red Hat > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: In need of C++ gurus
On Mon, Feb 20, 2017 at 09:15:46AM +0100, Jan Synacek wrote: > Hi, > > warzone2100 fails to build [1] and I have no idea how to fix that. > Most of the errors are: > > main_sdl.cpp:79:13: error: expected unqualified-id before '__attribute__' > static std::vector displaylist; // holds all our possible > display lists > ^ > main_sdl.cpp:117:29: error: cannot convert 'bool' to '__vector(4) > __bool int' in initialization > static bool mouseInWindow = true; > ^~~~ > main_sdl.cpp:148:22: error: cannot convert 'bool' to '__vector(4) > __bool int' in initialization > bool GetTextEvents = false; > ^ > > Could someone point me in the right direction? I've looked at [2], but > that doesn't seem to help much in this case. That looks like C++ and altivec.h on PowerPC. altivec.h changes the meaning of bool and vector keywords, so it is essential in what order and what mode you include it if you really need it (easiest is of course not include it at all). In general, for the non-ISO modes (i.e. -std=gnu++98, -std=gnu++11, -std=gnu++14, -std=gnu++17 etc.) altivec.h and preprocessor uses for these two context sensitive preprocessing, which usually works with most of the C++ code, while if you compile in strict ISO modes (-std=c++98, -std=c++11, -std=c++14, -std=c++17 etc.), then altivec.h redefines vector and bool to the altivec.h stuff, so in that case you must not include any standard C++ headers after including altivec.h and avoid bool/vector or #undef them if you want the standard C++ meaning of those (bool keyword and std::vector). So if you are using -std=c++* mode, easiest fix is to change it to -std=gnu++* mode. Otherwise you need to provide more details. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: In need of C++ gurus
On 02/20/2017 09:27 AM, Jakub Jelinek wrote: That looks like C++ and altivec.h on PowerPC. altivec.h changes the meaning of bool and vector keywords, so it is essential in what order and what mode you include it if you really need it (easiest is of course not include it at all). In general, for the non-ISO modes (i.e. -std=gnu++98, -std=gnu++11, -std=gnu++14, -std=gnu++17 etc.) altivec.h and preprocessor uses for these two context sensitive preprocessing, which usually works with most of the C++ code, while if you compile in strict ISO modes (-std=c++98, -std=c++11, -std=c++14, -std=c++17 etc.), then altivec.h redefines vector and bool to the altivec.h stuff, so in that case you must not include any standard C++ headers after including altivec.h and avoid bool/vector or #undef them if you want the standard C++ meaning of those (bool keyword and std::vector). Can we please put a #pragma into which enables the context-sensitive parsing even for the non-GNU modes? Including should be sufficient to turn on this kind of magic processing. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: In need of C++ gurus
On Mon, Feb 20, 2017 at 9:27 AM, Jakub Jelinek wrote: > On Mon, Feb 20, 2017 at 09:15:46AM +0100, Jan Synacek wrote: >> Hi, >> >> warzone2100 fails to build [1] and I have no idea how to fix that. >> Most of the errors are: >> >> main_sdl.cpp:79:13: error: expected unqualified-id before '__attribute__' >> static std::vector displaylist; // holds all our possible >> display lists >> ^ >> main_sdl.cpp:117:29: error: cannot convert 'bool' to '__vector(4) >> __bool int' in initialization >> static bool mouseInWindow = true; >> ^~~~ >> main_sdl.cpp:148:22: error: cannot convert 'bool' to '__vector(4) >> __bool int' in initialization >> bool GetTextEvents = false; >> ^ >> >> Could someone point me in the right direction? I've looked at [2], but >> that doesn't seem to help much in this case. > > That looks like C++ and altivec.h on PowerPC. altivec.h changes the > meaning of bool and vector keywords, so it is essential in what order > and what mode you include it if you really need it (easiest is of course > not include it at all). In general, for the non-ISO modes (i.e. > -std=gnu++98, -std=gnu++11, -std=gnu++14, -std=gnu++17 etc.) altivec.h > and preprocessor uses for these two context sensitive preprocessing, which > usually works with most of the C++ code, while if you compile in strict ISO > modes (-std=c++98, -std=c++11, -std=c++14, -std=c++17 etc.), then altivec.h > redefines vector and bool to the altivec.h stuff, so in that case you must > not include any standard C++ headers after including altivec.h and avoid > bool/vector or #undef them if you want the standard C++ meaning of those > (bool keyword and std::vector). > > So if you are using -std=c++* mode, easiest fix is to change it to > -std=gnu++* mode. Otherwise you need to provide more details. Thanks Dan and Jakub! There was a "-std=c++11" hidden in the configure, it was there because of some weird reason and simply removing it helped. -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
orphaning: sniproxy
Hello, I'm orphaning the sniproxy package because I no longer use it and haproxy seems to be quite superior in features/performance. If you are interested please consider adopting it. https://admin.fedoraproject.org/pkgdb/package/rpms/sniproxy/ regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
python-docker is in rawhide (was Re: heads up: update of python-docker-py to 2.x in rawhide)
I just built python-docker in rawhide. https://koji.fedoraproject.org/koji/buildinfo?buildID=860378 The biggest change is that `python-docker` does NOT provide `python-docker-py`, this means two things: 1. You can't have both packages installed. 2. You can still use `python-docker-py`. 3. You should switch to `python-docker`. python-docker-py will receive NO further updates. You can still use it, but upstream won't release anything new. As James Hogarth pointed out [1], since the version 2 is not backwards compatible with version 1, version 2 can't provide version 1. Hopefully, we'll be able to retire version 1 in Fedora 27. Please update your specfiles (and requirements.txt files) to point to version 2. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1422198#c7 Feel free to get in touch if you have any questions or comments. Regards, Tomas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
Quite frankly, I don't think Fedora is suitable for people with low bandwidth, simply because of its nature of updating policy. Even when using proxy with squid cache for packages, packages updates constantly and cache becomes obsolete very quickly. CentOS is much better choice. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
Le 2017-02-20 05:47, Fa Be a écrit : 1. It is huge for people of developing and un-developed countries. 2. It need to a DVD disc and DVD ROM for install via Optical Disc Drive (ODD). 3. It is a traffic wasting option, because all the software inside it is not necessarily used, like Libre Office, firefox, etc. 4. If Fedora can not installed on a system due to varios reasons, The DVD option is like above case, wasting network traffic. I think I provided reasonable grounds why the Fedora project should provide Minimal CD. Thank you Have you tried to use Fedora Cloud Base images? https://alt.fedoraproject.org/cloud/ It's about 128Mo You may convert qcow2 image with: * sudo apt-get install qemu-kvm * qemu-img convert test.qcow2 -O raw disk.img Here is the howto: http://askubuntu.com/questions/195139/how-to-convert-qcow2-virtual-disk-to-physical-machine-and-reversely ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
On Sun, 2017-02-19 at 18:08 -0500, Nico Kadel-Garcia wrote: > On Sun, Feb 19, 2017 at 3:50 PM, Matthew Miller > wrote: > > On Sun, Feb 19, 2017 at 11:29:37AM -, Fa Be wrote: > > > It will be very beneficial for people if the Fedora project > > > provides > > > the Minimal CD images of Fedora. It can attract more users to > > > Fedora > > > and is very useful for people who have the internt with > > > low-bandwidth. Currently I use Debian due to the lack of Minimal > > > CD > > > of Fedora. > > > > But then you need to add more stuff later, right? Isn't the network > > install + downloading specifically what you want a better option > > anyway? > > I agree that it can be very difficult to define "what you need to add > later". Gnome or even a compiler are undesirable on a stripped down > minimal fileserver with Samba capability. Spamassassin may be useful > on a mail server, but is pointless on anything else. Even the > netinstall ISO images are burdened by the frankly unnecessary X based > graphical installer. Anaconda didn't, and shouldn't, need graphical > displays to operate, and that has contributed to a "netinstall.iso" > of > nearly 500 MB for Fedora 25. Anaconda itself can work just fine without any GUI stuff being installed (GTK/X/etc.) - providing the text interface + kickstart installation support. That would make the image quite a bit smaller. It's just that AFAIK no such (text-only) Fedora installation image is actually being created at the moment. > There was a decision made to make the > installer itself much more graphically intense and to invent a new > "spoke and hub" based installation workflow. Unfortunately, if your > initial setup now requires a 500 MB download to get the bootstrap ISO > image with all the graphical components to operate at all, it > convinces me that making the installers so graphical was actually a > hindrance to developers. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[modularity] New documentation website
We have moved the documentation of the Modularity project from wiki [1] to Pagure Docs [2]! The documentation is build using Python Sphinx with custom theme that also includes the home page. To edit the documentation, please send pull-requests against the source repository [3]. [1] https://fedoraproject.org/wiki/Modularity [2] https://docs.pagure.org/modularity/ [3] https://pagure.io/modularity -- Adam Šamalík --- Software Engineer Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
And build your own kernel and compile other applications from source? Wouldn't that fragment the system? That might lead to dependency issues! CentOS is only good enough if he doesn't want the latest and greatest of everything! Or if he runs on old hardware. On Feb 20, 2017 17:21, "Samuel Rakitničan" wrote: > Quite frankly, I don't think Fedora is suitable for people with low > bandwidth, simply because of its nature of updating policy. Even when using > proxy with squid cache for packages, packages updates constantly and cache > becomes obsolete very quickly. CentOS is much better choice. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
> Le 2017-02-20 05:47, Fa Be a écrit : > > Have you tried to use Fedora Cloud Base images? > https://alt.fedoraproject.org/cloud/ > It's about 128Mo > > You may convert qcow2 image with: > * sudo apt-get install qemu-kvm > * qemu-img convert test.qcow2 -O raw disk.img > > Here is the howto: > http://askubuntu.com/questions/195139/how-to-convert-qcow2-virtual-disk-t... No, I did not know that and I don't think it could boot up a system, also it is not something that I need. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Reviews Weekly
Start Date: 2017-02-13 10:08:02.148870 End Date: 2017-02-20 10:08:02.148870 leigh scott : 4 https://bugzilla.redhat.com/show_bug.cgi?id=1422917 kmodtool https://bugzilla.redhat.com/show_bug.cgi?id=1424798 xed https://bugzilla.redhat.com/show_bug.cgi?id=1424825 xviewer https://bugzilla.redhat.com/show_bug.cgi?id=1424772 bluez-tools Jitka Plesnikova : 3 https://bugzilla.redhat.com/show_bug.cgi?id=1421142 perl-RDF-RDFa-Generator https://bugzilla.redhat.com/show_bug.cgi?id=1421166 perl-Config-ZOMG https://bugzilla.redhat.com/show_bug.cgi?id=1421081 perl-Code-TidyAll-Plugin-Test-Vars James Hogarth : 2 https://bugzilla.redhat.com/show_bug.cgi?id=1422198 python-docker https://bugzilla.redhat.com/show_bug.cgi?id=1413978 php-sabre-vobject4 Javier Peña : 2 https://bugzilla.redhat.com/show_bug.cgi?id=1422123 python-pykafka https://bugzilla.redhat.com/show_bug.cgi?id=1411201 js-jquery-file-upload Neal Gompa : 2 https://bugzilla.redhat.com/show_bug.cgi?id=1422697 resultsdb_conventions https://bugzilla.redhat.com/show_bug.cgi?id=1422689 python-openqa_client Randy Barlow : 2 https://bugzilla.redhat.com/show_bug.cgi?id=1408105 nodejs-p-is-promise https://bugzilla.redhat.com/show_bug.cgi?id=1415634 python-murano-pkg-check Raphael Groner : 2 https://bugzilla.redhat.com/show_bug.cgi?id=1420090 marble-subsurface https://bugzilla.redhat.com/show_bug.cgi?id=1420087 libdivecomputer-subsurface Tomas Tomecek : 2 https://bugzilla.redhat.com/show_bug.cgi?id=1421603 Request: https://bugzilla.redhat.com/show_bug.cgi?id=1421858 flannel-container Zbigniew Jędrzejewski-Szmek : 2 https://bugzilla.redhat.com/show_bug.cgi?id=1423377 prelude-lml-rules https://bugzilla.redhat.com/show_bug.cgi?id=1419226 prelude-correlator Alan Pevec : 1 https://bugzilla.redhat.com/show_bug.cgi?id=1422203 python-persist-queue Charles R. Anderson : 1 https://bugzilla.redhat.com/show_bug.cgi?id=1409869 perl-X10 Dan Callaghan : 1 https://bugzilla.redhat.com/show_bug.cgi?id=1420124 python-django-rest-framework-composed-permissions Eduardo Mayorga : 1 https://bugzilla.redhat.com/show_bug.cgi?id=1419259 rubygem-rake-contrib Kevin Fenzi : 1 https://bugzilla.redhat.com/show_bug.cgi?id=1422429 python-junit_xml Parag AN(पराग) : 1 https://bugzilla.redhat.com/show_bug.cgi?id=1424788 nodejs-safe-buffer Patrick Uiterwijk : 1 https://bugzilla.redhat.com/show_bug.cgi?id=1424861 python-hupper Piotr Popieluch : 1 https://bugzilla.redhat.com/show_bug.cgi?id=1370451 nodejs-grunt-contrib-copy Sascha Spreitzer : 1 https://bugzilla.redhat.com/show_bug.cgi?id=1419122 rubygem-base32 gil cattaneo : 1 https://bugzilla.redhat.com/show_bug.cgi?id=1423772 jchart2d Completed Review Requests: 31 This report was generated by bz-review-report.py. The original source is available at: https://git.fedorahosted.org/cgit/triage.git/tree/scripts/bzReviewReport.py ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
On Sun, Feb 19, 2017 at 03:50:33PM -0500, Matthew Miller wrote: > On Sun, Feb 19, 2017 at 11:29:37AM -, Fa Be wrote: > > It will be very beneficial for people if the Fedora project provides > > the Minimal CD images of Fedora. It can attract more users to Fedora > > and is very useful for people who have the internt with > > low-bandwidth. Currently I use Debian due to the lack of Minimal CD > > of Fedora. > > But then you need to add more stuff later, right? Isn't the network > install + downloading specifically what you want a better option > anyway? Not to mention first “dnf upgrade” after installation could easily replace half of distribution, with significant download size. That's why I prefer netinstall – one gets fresh updates during the installation. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
> And build your own kernel and compile other applications from source? > Wouldn't that fragment the system? That might lead to dependency issues! > CentOS is only good enough if he doesn't want the latest and greatest of > everything! Or if he runs on old hardware. > Almost all is available for CentOS also including latest kernels from third party repoes. http://elrepo.org/tiki/kernel-ml ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Bodhi 2.4.0 deployed
Hello Fedora devs! Today I deployed Bodhi 2.4.0 to production. It's got a few new features and some bug fixes. You can read the release notes here: https://github.com/fedora-infra/bodhi/blob/2.4.0/docs/release_notes.rst#240 If you find issues with Bodhi, please let us know! https://github.com/fedora-infra/bodhi/issues/new signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: errors or bugs !?
Michael Catanzaro wrote: > On Sun, 2017-02-19 at 13:57 +0200, Catalin wrote: >> - can you see multiple detections of Krita and Rhythmbox? > > Please file two separate bugs against Krita and Rhythmbox. Krita provides 1 desktop file per mimetype supported (each with NoDisplay=true). This should be a valid use-case as far as I can tell, so isn't a krita bug. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
Replies inline On 20.02.2017 04:47, Fa Be wrote: >> On Sun, Feb 19, 2017 at 11:29:37AM -, Fa Be wrote: But then you need to >> add more stuff later, right? Isn't the network install + downloading >> specifically what you want a better option anyway? > > First of all I must say I assume that the Minimal CD of CentOS provides the > GNOME Desktop like Debian #1 CD, based on this assumption, adding more stuff > is not always necessary. Don't think only to me, imagine there is many old > and network-less systems in one place which needs to a graphical environment > like GNOME for file system browsing, image viewing, trying GNOME, etc. The > Net install option is not efficient for this purpose and Live DVD has several > problems: > > 1. It is huge for people of developing and un-developed countries. > *** DVD /USB images are available and need no internet / networking beyond > LAN / NFS ( assuming local mirrors) > > 2. It need to a DVD disc and DVD ROM for install via Optical Disc Drive (ODD). > *** DVD images can and are recommended even these days to be burned to usb > via Fedora Media Creator, live-iso-to-disk, or simple dd > > 3. It is a traffic wasting option, because all the software inside it is not > necessarily used, like Libre Office, firefox, etc. > *** Using a kickstart can / does alleviate MOST of this issue -- Guides are > on the wiki for this, Secondly ( assuming root pass or sudo use is available > copy /root/anaconda-ks.cfg to somewhere in your /home/ space and > remove what is not needed ( That file is the kickstart that created your > presently working/installed system ( in the event you'd rather not create it > from scratch) > > 4. If Fedora can not installed on a system due to various reasons, The DVD > option is like above case, wasting network traffic. > *** Again, assuming you have media from an event OR the freemedia sub project > that is no longer an issue. > > I think I provided reasonable grounds why the Fedora project should provide > Minimal CD. Thank you > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org sent via webmail, pardon lack of gpg signature. -- Corey W Sheldon ph: +1 (310).909.7672 0x8B4E89435A88E539 0x59276298D2264944 Freelance IT Consultant, Multi-Discipline Tutor Fedora AmbaNA (linuxmodder) Ameridea LLC Founder, President Find me elsewhere: https://gist.github.com/linux-modder/ac5dc6fa211315c633c9 "One must never underestimate the power of boredom...from which creativity and laziness are borne, which can spark great works of chaos and genius." --Anonymous "Any man willing to retreat freedom for security is deserving of neither." (Pp) -- Benjamin Franklin. This document, including attachments, is intended for the person or company named and contains confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please destroy this message and notify the sender. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
On Sun, 2017-02-19 at 23:45 +, Personal (open) wrote: > DVD IS ALSO in Workstation and is routinely given out at events. That's the live image. When we say 'DVD' we don't just mean 'any ISO written to a DVD', it has a specific meaning for Fedora (and RH) images: it's an installer image containing a package repository. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
On Mon, 2017-02-20 at 04:47 +, Fa Be wrote: > First of all I must say I assume that the Minimal CD of CentOS > provides the GNOME Desktop like Debian #1 CD It does not, no. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: time to retire some kde4/smoke-based language bindings?
Per old thread, https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D4QXJ5HBCNJJYWHB7SPOQWL57QMMC63O/ kde-sig retired kdebindings (virtual package), and orphaned the following today: kimono ruby-korundum ruby-qt smokeqt smokekde qyoto -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
Allright everybody, thanks for your response, I became convinced that there is no need to Minimal CD of Fedoa. I understand that if a system is so old that does not have USB port, Fedora in not siutable for it, and must try CentOS or something lighter and LEGACY!, and 1.3GB for DVD is not too much high these days, instead it included many sotware which is used by most users, there are also "Fedora Free Media Program" and CentOS. I will install and try Fedora via Net Install at few weeks later, when I charged my internet service. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: errors or bugs !?
On Mon, 2017-02-20 at 09:21 -0600, Rex Dieter wrote: > Krita provides 1 desktop file per mimetype supported (each with > NoDisplay=true). > > This should be a valid use-case as far as I can tell, so isn't a > krita bug. Ah yeah, that's interesting. Rhythmbox does too. Looks like I incorrectly assumed that the applications were doing something wrong with their desktop files. OK, so just one bug report then, against Nautilus. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
> On Mon, 2017-02-20 at 04:47 +, Fa Be wrote: > > It does not, no. Why? Do you know how Debian can do it and what is differences between CentOS and Debian in the field of default software? I can guess some: SELinux, Installer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
On Mon, 2017-02-20 at 17:02 +, Fa Be wrote: > > On Mon, 2017-02-20 at 04:47 +, Fa Be wrote: > > > > It does not, no. > > Why? Do you know how Debian can do it and what is differences between > CentOS and Debian in the field of default software? > > I can guess some: > > SELinux, Installer No. I don't have sufficient experience with Debian's system to know what the differences may be. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
El lun, 20-02-2017 a las 08:10 -0800, Adam Williamson escribió: > On Sun, 2017-02-19 at 23:45 +, Personal (open) wrote: > > DVD IS ALSO in Workstation and is routinely given out at events. > > That's the live image. When we say 'DVD' we don't just mean 'any ISO > written to a DVD', it has a specific meaning for Fedora (and RH) > images: it's an installer image containing a package repository. Which server does have, It is slightly bigger than a minimal install, but not much. It is likely what is wanted. Dennis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
On Mon, 2017-02-20 at 11:31 -0600, Dennis Gilmore wrote: > El lun, 20-02-2017 a las 08:10 -0800, Adam Williamson escribió: > > On Sun, 2017-02-19 at 23:45 +, Personal (open) wrote: > > > DVD IS ALSO in Workstation and is routinely given out at events. > > > > That's the live image. When we say 'DVD' we don't just mean 'any ISO > > written to a DVD', it has a specific meaning for Fedora (and RH) > > images: it's an installer image containing a package repository. > > Which server does have, It is slightly bigger than a minimal install, > but not much. It is likely what is wanted. Well, it's 2.8GiB. The default install it does isn't very large, but it includes various server package sets which bump up the image size. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: time to retire some kde4/smoke-based language bindings?
On Seg, 2017-02-20 at 10:39 -0600, Rex Dieter wrote: > Per old thread, > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje > ct.org/thread/D4QXJ5HBCNJJYWHB7SPOQWL57QMMC63O/ > > kde-sig retired kdebindings (virtual package), and orphaned the > following > today: > > kimono > ruby-korundum > ruby-qt > smokeqt > smokekde > qyoto "Of these, I can see *maybe* keeping perl-Qt (and dep smokeqt), primarily because it is the only one in this list that's not a leaf package (debconf- kde depends on it). " debconf-kde still need perl-Qt and perl-Qt use libQtCore.so.4 and also depends on smokeqt why we want orphan qt4 bindings ? BTW I just add some of these packages to epel7 [1] What is your advise, idea or notes ? [1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d90518ab91 > -- Rex > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F27 System Wide Change: No More Alphas
= Proposed System Wide Change: No More Alphas = https://fedoraproject.org/wiki/Changes/NoMoreAlpha Change owner(s): * Dennis Gilmore * Adam Williamson Fedora will no longer produce Alpha releases. == Detailed Description == By gating Rawhide builds from landing in the compose and gating the publication of composes on automated test results we will ensure Rawhide will always be at Alpha quality. This will make it more generally useful to people as a daily driver and development platform, and mean we no longer need to go through the process of building, testing and shipping Alpha releases. The initial testing will be ensuring that a package is installable and that it does not break existing packages installation. Over time we can enable extra testing to gate the build going into rawhide. Builds will land in the buildroot to be built against before they make it to the compose. == Scope == * Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they meet gating criteria. The changes would start to be implemented in rawhide shortly after branching Fedora 26 * Other developers: Pay attention to new notifications and act when necessary * Release engineering: https://pagure.io/releng/issue/6621 * List of deliverables: This change removes a milestone and all associated deliverables * Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change implementation that currently needs to be checked at Alpha * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: time to retire some kde4/smoke-based language bindings?
Sérgio Basto wrote: > On Seg, 2017-02-20 at 10:39 -0600, Rex Dieter wrote: >> Per old thread, >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje >> ct.org/thread/D4QXJ5HBCNJJYWHB7SPOQWL57QMMC63O/ >> >> kde-sig retired kdebindings (virtual package), and orphaned the >> following >> today: >> >> kimono >> ruby-korundum >> ruby-qt >> smokeqt >> smokekde >> qyoto > > "Of these, I can see *maybe* keeping perl-Qt (and dep smokeqt), > primarily because it is the only one in this list that's not a leaf > package (debconf- kde depends on it). " > > debconf-kde still need perl-Qt and perl-Qt use libQtCore.so.4 and also > depends on smokeqt > > why we want orphan qt4 bindings ? > BTW I just add some of these packages to epel7 [1] What is your advise, > idea or notes ? Note we only orphaned these (not eol/retired). If you have any interest in keeping these alive, feel free to take them. Be warned, most(all?) of them are unmaintained upstream and have rawhide FTBFS issues. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On 02/20/2017 06:44 PM, Jan Kurik wrote: = Proposed System Wide Change: No More Alphas = https://fedoraproject.org/wiki/Changes/NoMoreAlpha Change owner(s): * Dennis Gilmore * Adam Williamson Fedora will no longer produce Alpha releases. -1 from me. This plan is not applicable and will kill Fedora. The effects to be expected are similar to those you see in current (20-02-2017) Fedora rawhide. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Any voluteers for maintaining xml-security-c?
Hey. I'm looking volunteers for maintaining xml-security-c package in Fedora. Current version is old in our repos and for example esteid (Estonian ID card) packages depend on newer xml-security-c (with openssl 1.1 support). I've already contacted anttix who is current package administrator to give committer rights to bruno and also contacted bruno to find out if he is still interested in maintaining it. Negative. And I'm also not too confident of maintaining it because of lack of in depth knowledge what I might end up with. So I'm seeking towards devel list to find out, are there any volunteers with enough courage to update and maintain it. https://admin.fedoraproject.org/pkgdb/package/rpms/xml-security-c/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
Just my 2 cents A minimal fedora iso with @base and @core packages can the tool for a advanced user to build it own fedora experience on top a minimal install. If I want just lightdm and i3, openbox, awesome etc a minimal installable fedora iso than do not requiere internet access at install time will be a excellent option. Regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: errors or bugs !?
I hope some problems will be fixed into the new Fedora 26 1. I think is the script from Nautilus who find the software ... I can fill a bug report because I'm not into development team. I show you just to see if is a common error. Also some label test need to be changed from "Open With Other Application" to something similar - "Try to open with application" all words are upercase, and this is not the great way to have a finish task with that task. maybe will not be open with the application 2. will be great also if we can see all row with blue color from Find New Application for software installed not just that little blue square. also the correct way is: "Try with a new application" or "Find a new application to ..." OK, so just one bug report then, against Nautilus. > > Michael > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
El lun, 20-02-2017 a las 19:13 +0100, Ralf Corsepius escribió: > On 02/20/2017 06:44 PM, Jan Kurik wrote: > > = Proposed System Wide Change: No More Alphas = > > https://fedoraproject.org/wiki/Changes/NoMoreAlpha > > > > Change owner(s): > > * Dennis Gilmore > > * Adam Williamson > > > > Fedora will no longer produce Alpha releases. > > -1 from me. This plan is not applicable and will kill Fedora. > > The effects to be expected are similar to those you see in current > (20-02-2017) Fedora rawhide. > I do not get what you mean by your statement, it is extremely vague with no detail. can you please expand on it in the context of the change? and the changes it will bring to the entire workflow of rawhide? Dennis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please provide "Minimal CD" of Fedora
On Mon, Feb 20, 2017 at 11:15 AM William Moreno wrote: > Just my 2 cents > > A minimal fedora iso with @base and @core packages can the tool for a > advanced user to build it own fedora experience on top a minimal install. > > If I want just lightdm and i3, openbox, awesome etc a minimal installable > fedora iso than do not requiere internet access at install time will be a > excellent option. > > Regards > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org The openSUSE installer (both net and DVD-with-packages) includes a "Minimal X" install option. I don't remember what's in it but the window manager is IceWM, a ratty-looking but serviceable GUI. I think it includes Firefox but maybe a lighter browser is there. You can do the same from the Fedora net install. It would be pretty easy to make a lightweight Live CD with a minimal GUI, a lightweight browser and the Anaconda installer as a Fedora remix. But personally I'd rather see the effort go into building up the "Atomic Desktop" as a lightweight Fedora. -- How many people can stand on the shoulders of a giant before the giant collapses? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
gcc7 issue with efl + aarch64
I'm stumped here. efl builds against all rawhide arches except aarch64, where it has started failing like this (since gcc 7): https://kojipkgs.fedoraproject.org//work/tasks/2376/17972376/build.log libtool: link: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fpie -Wl,-z -Wl,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fPIC -DPIC -pie -rdynamic -o bin/elua/.libs/elua bin/elua/bin_elua_elua-main.o -fvisibility=hidden -fdata-sections -ffunction-sections -Wl,--gc-sections -fno-strict-aliasing -Wl,--as-needed -Wl,--no-copy-dt-needed-entries -fvisibility=hidden -fdata-sections -ffunction-sections -Wl,--gc-sections -fno-strict-aliasing -Wl,--as-needed -Wl,--no-copy-dt-needed-entries lib/ecore_file/.libs/libecore_file.so lib/ecore/.libs/libecore.so lib/efl/.libs/libefl.so lib/eo/.libs/libeo.so lib/eina/.libs/libeina.so lib/elua/.libs/libelua.so -lluajit-5.1 /builddir/build/BUILD/efl-1.18.4/src/lib/ecore_file/.libs/libecore_file.so /builddir/build/BUILD/efl-1.18.4/src/lib/ecore_con/.libs/libecore_con.so /builddir/build/BUILD/efl-1.18.4/src/lib/eet/.libs/libeet.so /builddir/build/BUILD/efl-1.18.4/src/lib/emile/.libs/libemile.so -lssl -lcrypto -lz -ljpeg /builddir/build/BUILD/efl-1.18.4/src/lib/ecore/.libs/libecore.so -lgthread-2.0 -lglib-2.0 /builddir/build/BUILD/efl-1.18.4/src/lib/efl/.libs/libefl.so /builddir/build/BUILD/efl-1.18.4/src/lib/eo/.libs/libeo.so /builddir/build/BUILD/efl-1.18.4/src/lib/eina/.libs/libeina.so -lsystemd -lm -ldl -lrt -lpthread -pthread libtool: link: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fpie -Wl,-z -Wl,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fPIC -DPIC -pie -rdynamic -o bin/eeze/.libs/eeze_udev_test bin/eeze/bin_eeze_eeze_udev_test-eeze_udev_test.o -fvisibility=hidden -fdata-sections -ffunction-sections -Wl,--gc-sections -fno-strict-aliasing -Wl,--as-needed -Wl,--no-copy-dt-needed-entries lib/emile/.libs/libemile.so lib/eet/.libs/libeet.so lib/ecore_con/.libs/libecore_con.so lib/ecore_file/.libs/libecore_file.so lib/efl/.libs/libefl.so lib/eo/.libs/libeo.so lib/ecore/.libs/libecore.so lib/eina/.libs/libeina.so lib/eeze/.libs/libeeze.so -lmount -ludev /builddir/build/BUILD/efl-1.18.4/src/lib/ecore_file/.libs/libecore_file.so /builddir/build/BUILD/efl-1.18.4/src/lib/ecore_con/.libs/libecore_con.so /builddir/build/BUILD/efl-1.18.4/src/lib/eet/.libs/libeet.so /builddir/build/BUILD/efl-1.18.4/src/lib/emile/.libs/libemile.so -lssl -lcrypto -lz -ljpeg /builddir/build/BUILD/efl-1.18.4/src/lib/ecore/.libs/libecore.so -lgthread-2.0 -lglib-2.0 /builddir/build/BUILD/efl-1.18.4/src/lib/efl/.libs/libefl.so /builddir/build/BUILD/efl-1.18.4/src/lib/eo/.libs/libeo.so /builddir/build/BUILD/efl-1.18.4/src/lib/eina/.libs/libeina.so -lsystemd -lm -ldl -lrt -lpthread -pthread /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fpie -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fPIC -DPIC -pie -rdynamic -o bin/eeze/eeze_sensor_test bin/eeze/bin_eeze_eeze_sensor_test-eeze_sensor_test.o -fvisibility=hidden -fdata-sections -ffunction-sections -Wl,--gc-sections -fno-strict-aliasing -Wl,--as-needed -Wl,--no-copy-dt-needed-entries-lmount -ludev lib/emile/libemile.la lib/eet/libeet.la lib/ecore_con/libecore_con.la lib/ecore_file/libecore_file.la lib/efl/libefl.la lib/eo/libeo.la lib/ecore/libecore.la lib/eina/libeina.la -lpthread lib/eeze/libeeze.la ELUA_EOLIAN_LIBRARY_PATH=../src/lib/eolian/.libs ../src/bin/elua/elua -I/builddir/build/BUILD/efl-1.18.4/src/bindings/luajit -C/builddir/build/BUILD/efl-1.18.4/src/scripts/elua/core -M/builddir/build/BUILD/efl-1.18.4/src/scripts/elua/modules -A/builddir/build/BUILD/efl-1.18.4/src/scripts/elua/apps lualian -I. -o lib/ecore_audio/ecore_audio.eo.lua lib/ecore_audio/ecore_audio.eo make[4]: *** [Makefile:52023: lib/ecore_audio/ecore_audio.eo.lua] Segmentation fault (core dumped) make[4]: *** Waiting for unfinished jobs Any gcc gurus have any thoughts? I don't have an aarch64 setup, but even if I did, this isn't much to go on. ~tom == Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
Dennis Gilmore wrote: > I do not get what you mean by your statement, it is extremely vague > with no detail. can you please expand on it in the context of the > change? and the changes it will bring to the entire workflow of > rawhide? Rawhide is just nowhere near working, half the packages have broken dependencies due to not building with the latest GCC. If you really implement your gating idea to "fix" that, this means the mass rebuild (and the new GCC!) could NOT be tagged until ALL the broken dependencies are fixed. That may take months. Or you freeze GCC (and similar packages) on a fixed version forever and never upgrade it again (kinda like in the old RHL 7.x days where that 2.96 snapshot was kept even when 3.2 was current). If that (withholding new compilers for months until all packages work with them) is not the plan, then the gating will not do any good, because that is where the breakage comes from, not updates of leaf packages. Also keep in mind that we already killed the "Alphas" once, the current "Alpha" is already what used to be the "Beta". Now we want to keep only the current "Beta" = old "Preview". I think fewer freezes is not necessarily a bad thing, but are we really ready for that? I would like to see the gating system in action first to see whether it can really keep Rawhide in release quality all the time. I am highly sceptical, given the major changes that go into Rawhide. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On 02/20/2017 08:47 PM, Dennis Gilmore wrote: El lun, 20-02-2017 a las 19:13 +0100, Ralf Corsepius escribió: On 02/20/2017 06:44 PM, Jan Kurik wrote: = Proposed System Wide Change: No More Alphas = https://fedoraproject.org/wiki/Changes/NoMoreAlpha Change owner(s): * Dennis Gilmore * Adam Williamson Fedora will no longer produce Alpha releases. -1 from me. This plan is not applicable and will kill Fedora. The effects to be expected are similar to those you see in current (20-02-2017) Fedora rawhide. I do not get what you mean by your statement, it is extremely vague with no detail. can you please expand on it in the context of the change? and the changes it will bring to the entire workflow of rawhide? No. Mr. Williamson's attitude towards the Fedora community makes it impossible to answer. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: gcc7 issue with efl + aarch64
On Mon, 2017-02-20 at 16:51 -0500, Tom Callaway wrote: > Segmentation fault (core dumped) > make[4]: *** Waiting for unfinished jobs > > Any gcc gurus have any thoughts? I don't have an aarch64 setup, but > even > if I did, this isn't much to go on. I would ask the systems team for help with getting access to one of the builders, so that you can get a core dump for that segmentation fault. You're not going to figure out what's going on without it. My guess is that GCC is crashing. You'll need it for a bug report anyway. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, Feb 20, 2017 at 5:20 PM, Kevin Kofler wrote: > Dennis Gilmore wrote: >> I do not get what you mean by your statement, it is extremely vague >> with no detail. can you please expand on it in the context of the >> change? and the changes it will bring to the entire workflow of >> rawhide? > > Rawhide is just nowhere near working, half the packages have broken > dependencies due to not building with the latest GCC. If you really > implement your gating idea to "fix" that, this means the mass rebuild (and > the new GCC!) could NOT be tagged until ALL the broken dependencies are > fixed. That may take months. Or you freeze GCC (and similar packages) on a > fixed version forever and never upgrade it again (kinda like in the old RHL > 7.x days where that 2.96 snapshot was kept even when 3.2 was current). If > that (withholding new compilers for months until all packages work with > them) is not the plan, then the gating will not do any good, because that is > where the breakage comes from, not updates of leaf packages. > > Also keep in mind that we already killed the "Alphas" once, the current > "Alpha" is already what used to be the "Beta". Now we want to keep only the > current "Beta" = old "Preview". > > I think fewer freezes is not necessarily a bad thing, but are we really > ready for that? I would like to see the gating system in action first to see > whether it can really keep Rawhide in release quality all the time. I am > highly sceptical, given the major changes that go into Rawhide. > I also wonder if we're thinking about this problem all wrong. What if the answer isn't to increase the friction in Rawhide, but instead to create a regular output stream that people can use to be above releases? That's more or less how Tumbleweed works, as it's essentially snapshotted and published from Factory when it "checks out" via the OpenQA gate. Now, OBS has the nice ability of being able to have granular control of how publishing actually works. I think the way Koji's tagging mechanism works may provide a similar capability, and we could leverage that to produce something like mattdm's oft-wanted "Fedora Bikeshed". I for one don't actually want Rawhide to be gated because it makes things much harder in terms of properly developing new features. We're simply not capable of being as good as OpenSUSE in terms of automation to be able to pull off the feats they do. There were major changes to how OpenSUSE did packaging to begin with to be able to pull off what they did, and I simply don't think anyone here is prepared to do even a small bit of that yet. And before someone brings up Factory 2.0 and Modularity (because someone *will*), neither of those solve the problem. Instead they create new ones by completely decoupling package life cycles from the distribution lifecycle (meaning that now it's even harder to introduce distribution-wide changes) and requiring us to shimmy in ways to handle multiple versions for creating weird bundles without being prepared to figure out how to actually keep that sane. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: gcc7 issue with efl + aarch64
On 02/20/2017 03:09 PM, Michael Catanzaro wrote: On Mon, 2017-02-20 at 16:51 -0500, Tom Callaway wrote: Segmentation fault (core dumped) make[4]: *** Waiting for unfinished jobs Any gcc gurus have any thoughts? I don't have an aarch64 setup, but even if I did, this isn't much to go on. I would ask the systems team for help with getting access to one of the builders, so that you can get a core dump for that segmentation fault. You're not going to figure out what's going on without it. My guess is that GCC is crashing. You'll need it for a bug report anyway. According to the log https://kojipkgs.fedoraproject.org//work/tasks/2376/17972376/build.log gcc has completed execution. It is ../src/bin/elua/elua that gets SIGSEGV for target lib/ecore_audio/ecore_audio.eo.lua : ELUA_EOLIAN_LIBRARY_PATH=../src/lib/eolian/.libs ../src/bin/elua/elua -I/builddir/build/BUILD/efl-1.18.4/src/bindings/luajit -C/builddir/build/BUILD/efl-1.18.4/src/scripts/elua/core -M/builddir/build/BUILD/efl-1.18.4/src/scripts/elua/modules -A/builddir/build/BUILD/efl-1.18.4/src/scripts/elua/apps lualian -I. -o lib/ecore_audio/ecore_audio.eo.lua lib/ecore_audio/ecore_audio.eo make[4]: *** [Makefile:52023: lib/ecore_audio/ecore_audio.eo.lua] Segmentation fault (core dumped) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, Feb 20, 2017 at 6:42 PM Ralf Corsepius > > No. Mr. Williamson's attitude towards the Fedora community makes it > impossible to answer Without details, a vague discussion adds nothing meaningful to the conversation. Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, 20 Feb 2017 18:24:21 -0500 Neal Gompa wrote: > On Mon, Feb 20, 2017 at 5:20 PM, Kevin Kofler > wrote: > > Dennis Gilmore wrote: > >> I do not get what you mean by your statement, it is extremely vague > >> with no detail. can you please expand on it in the context of the > >> change? and the changes it will bring to the entire workflow of > >> rawhide? > > > > Rawhide is just nowhere near working, half the packages have broken > > dependencies due to not building with the latest GCC. Thats a bit over dramatic don't you think? 968 currently on the FTBFS list, and even there many of those don't have broken deps because the previous build still works. > If you really > > implement your gating idea to "fix" that, this means the mass > > rebuild (and the new GCC!) could NOT be tagged until ALL the broken > > dependencies are fixed. That may take months. Or you freeze GCC > > (and similar packages) on a fixed version forever and never upgrade > > it again (kinda like in the old RHL 7.x days where that 2.96 > > snapshot was kept even when 3.2 was current). If that (withholding > > new compilers for months until all packages work with them) is not > > the plan, then the gating will not do any good, because that is > > where the breakage comes from, not updates of leaf packages. Yeah, the mass rebuild case will need to be excepted once it's "good enough" or have some other way of landing... > I also wonder if we're thinking about this problem all wrong. What if > the answer isn't to increase the friction in Rawhide, but instead to > create a regular output stream that people can use to be above > releases? That's more or less how Tumbleweed works, as it's > essentially snapshotted and published from Factory when it "checks > out" via the OpenQA gate. Now, OBS has the nice ability of being able > to have granular control of how publishing actually works. I think the > way Koji's tagging mechanism works may provide a similar capability, > and we could leverage that to produce something like mattdm's > oft-wanted "Fedora Bikeshed". I think we can have a more stable rawhide without going to a higher level here. I think there's several parts here when we talk about rawhide stability: 1. Compose stability. I think gating things here and stopping the stuff that breaks things until it doesn't will be a big win. Thats basically what we do now, except it takes a bunch of people time to find out nss broke something, then rdma-core broke something, then something (turns out to be policycoreutils and setools pulls in 600 new packages) breaks things. Also sometimes we have images, sometimes we don't. 2. Install stability. The stuff autoqa is testing now. This is often broken and some human has to sort it out. 3. Day to day use. This is seldom really broken these days. There's things every once in a while, but overall it's not bad. Anyhow, I am in favor of the proposal. kevin pgpjCh2v4ZXL_.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, Feb 20, 2017 at 3:26 PM Neal Gompa wrote: > I also wonder if we're thinking about this problem all wrong. What if > the answer isn't to increase the friction in Rawhide, but instead to > create a regular output stream that people can use to be above > releases? That's more or less how Tumbleweed works, as it's > essentially snapshotted and published from Factory when it "checks > out" via the OpenQA gate. Now, OBS has the nice ability of being able > to have granular control of how publishing actually works. I think the > way Koji's tagging mechanism works may provide a similar capability, > and we could leverage that to produce something like mattdm's > oft-wanted "Fedora Bikeshed". > > I for one don't actually want Rawhide to be gated because it makes > things much harder in terms of properly developing new features. We're > simply not capable of being as good as OpenSUSE in terms of automation > to be able to pull off the feats they do. There were major changes to > how OpenSUSE did packaging to begin with to be able to pull off what > they did, and I simply don't think anyone here is prepared to do even > a small bit of that yet. > > And before someone brings up Factory 2.0 and Modularity (because > someone *will*), neither of those solve the problem. Instead they > create new ones by completely decoupling package life cycles from the > distribution lifecycle (meaning that now it's even harder to introduce > distribution-wide changes) and requiring us to shimmy in ways to > handle multiple versions for creating weird bundles without being > prepared to figure out how to actually keep that sane. > > I'm glad someone brought up Tumbleweed because every so often I build a VM of Tumbleweed, a VM of Rawhide and a VM of Debian "sid" just to see if I could use any of them as a workstation day-to-day. What I'm looking for mostly is the latest GNOME desktop, Firefox browser, Virtual Machine Manager stack and Docker stack. LibreOffice is nice but I can live without it, given that I have RStudio Server and PostgreSQL / PostGIS running in (Debian) containers. Rawhide as it currently exists can't stay solid enough for me even with just the few pieces I absolutely need. Tumbleweed, for all it's promise of "latest and greatest", is not supported by enough third parties to be useful even as just a host. And sid is, well, sid. If there was a "Fedora GNOME Tumbleweed" I would absolutely use it, because the rest of Fedora's container stack - OpenShift Origin, source-to-image, etc. - is way better than what's in Tumbleweed or Sid. Sure, I could build that stuff from source but I don't want to waste the troubleshooting time. -- How many people can stand on the shoulders of a giant before the giant collapses? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, Feb 20, 2017 at 4:11 PM Kevin Fenzi wrote: > Anyhow, I am in favor of the proposal. > Yes, so am I, at least until Atomic Workstation has a full GNOME desktop, Firefox and Virtual Machine Manager ;-). -- How many people can stand on the shoulders of a giant before the giant collapses? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, 2017-02-20 at 18:24 -0500, Neal Gompa wrote: > I for one don't actually want Rawhide to be gated because it makes > things much harder in terms of properly developing new features. We're > simply not capable of being as good as OpenSUSE in terms of automation > to be able to pull off the feats they do. There were major changes to > how OpenSUSE did packaging to begin with to be able to pull off what > they did, and I simply don't think anyone here is prepared to do even > a small bit of that yet. This is vague and non-actionable. What, specifically, do you think will be a problem, and what, specifically, do you think needs changing to fix the problem? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Tue, 21 Feb 2017 00:14:56 + "M. Edward (Ed) Borasky" wrote: ...snip... > > Rawhide as it currently exists can't stay solid enough for me even > with just the few pieces I absolutely need. Tumbleweed, for all it's > promise of "latest and greatest", is not supported by enough third > parties to be useful even as just a host. And sid is, well, sid. I'm curious what issues you hit with Rawhide? Have any examples? kevin pgpCA9ajy5z2v.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On 02/21/2017 01:48 AM, Kevin Fenzi wrote: On Tue, 21 Feb 2017 00:14:56 + "M. Edward (Ed) Borasky" wrote: ...snip... Rawhide as it currently exists can't stay solid enough for me even with just the few pieces I absolutely need. Tumbleweed, for all it's promise of "latest and greatest", is not supported by enough third parties to be useful even as just a host. And sid is, well, sid. I'm curious what issues you hit with Rawhide? Have any examples? Current rawhide (== Feb 15) does not match with what the builders use. => It's impossible to locally investigate runtime bugs Real world example: https://bugzilla.redhat.com/show_bug.cgi?id=1425129 Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Tue, 2017-02-21 at 01:56 +0100, Ralf Corsepius wrote: > On 02/21/2017 01:48 AM, Kevin Fenzi wrote: > > On Tue, 21 Feb 2017 00:14:56 + > > "M. Edward (Ed) Borasky" wrote: > > ...snip... > > > > > > > > Rawhide as it currently exists can't stay solid enough for me even > > > with just the few pieces I absolutely need. Tumbleweed, for all it's > > > promise of "latest and greatest", is not supported by enough third > > > parties to be useful even as just a host. And sid is, well, sid. > > > > I'm curious what issues you hit with Rawhide? Have any examples? > > Current rawhide (== Feb 15) does not match with what the builders use. > => It's impossible to locally investigate runtime bugs [adamw@adam productmd (parse-cid)]$ cat /etc/yum.repos.d/koji.repo [koji] name=koji baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/ cost=2000 enabled=1 Please don't do this as a matter of course, because kojipkgs only has so much capacity. But when composes are failing, you can do this to get the latest packages. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, Feb 20, 2017 at 7:24 PM, Adam Williamson wrote: > On Mon, 2017-02-20 at 18:24 -0500, Neal Gompa wrote: >> I for one don't actually want Rawhide to be gated because it makes >> things much harder in terms of properly developing new features. We're >> simply not capable of being as good as OpenSUSE in terms of automation >> to be able to pull off the feats they do. There were major changes to >> how OpenSUSE did packaging to begin with to be able to pull off what >> they did, and I simply don't think anyone here is prepared to do even >> a small bit of that yet. > > This is vague and non-actionable. What, specifically, do you think will > be a problem, and what, specifically, do you think needs changing to > fix the problem? So, off the top of my head, there are a few things here: * Version-Release formatting in Fedora packages is too complicated. We store part of the upstream versioning in the Release field, making it way more difficult to safely and sanely bump the release automatically. Moving that information out of Release and back into Version (where it belongs) drastically simplifies the Release field, which leads to... * Automatic rebuilding of dependency chains and submitting them as part of updates. Right now, it's a ton of work to go through and find the reverse dependencies of a package and build that chain and submit it as part of an update. It should be that once someone has updated a package past some kind of dependency drift point (could be any update bumping the version or based on library soname or whatever), the reverse dependencies should automatically be calculated, bumped with an automatically generated changelog entry and release field bump, and appended to an update (or just rebuilt and merged right back in after an update package is pushed). There is way too much grunt work involved in building dependency chains, and we don't seem to have any will to fix that. Koschei already does a lot of this with scratch building, but I do not think they should be scratch builds, and instead should be actually submitted. * We need actual post-build checks to occur right after the build, using rpmlint and other tools. Right now, no one knows *anything* about the usefulness of a package until we submit to Bodhi. That's *way* too late in my view, and doesn't even make sense. As far as I know, Koji has some (weak) support for post-build checks like SUSE's OBS has, and we should be incorporating things like rpmlint, package scans, etc. that Taskotron does as part of a post-build check *before* updates are submitted. And the general disdain for package linting needs to die. Being sloppy with our packaging because we can't know whether our own tools are telling us the right thing is a terrible thing. Some other nice-to-haves that should probably make our lives a bit easier: * Finding ways to eliminate Epoch as a general matter of consideration for packagers. That means figuring out how to retool Fedora so that Epoch doesn't need to persist beyond a single release. We can already handle this with distro-sync in DNF, but if there are other pieces, they need to be fixed up too. At first glance, this doesn't seem like something all that important, but Epoch throws people off quite a bit when setting up package dependencies, because it's not a field that we usually use, and it's not always obvious when we're using it. Not to mention, now that we don't actually need it to ensure upgrade paths, we should try to get rid of it whenever we can. And this business of "rawhide going down being bad" needs to die in a fire, since nobody should be reasonably NOT using distro-sync in Rawhide or going to a new Fedora release. * Pushing to eliminate more scriptlets that people have to drop into packages. Either turn the scriptlets into one-liner macros, turn them into file triggers, or turn them into some kind of inotify thing so that people *do not have to think about them*. Ideally the Scriptlets page in the wiki[1] should be nearly all including warnings that they aren't to be used in Fedora. We've actually made some good progress on this, but we've stalled out a bit... * A dedicated application for doing package reviews. Bugzilla is horrible for this. If you think Bugzilla is a good tool for this, then you have Stockholm Syndrome somehow, because it's a really crappy workflow. Ideally, it should be something that plugs into our build infrastructure, so that as changes are made during a package review, they are tracked and the reviewer can see the differences as they come. OpenSUSE's OBS actually has this built into their system. The "submit requests" provide exactly the same functionality in a rather lightweight manner, and allow reviewers to look at *everything*, including the contents of tarballs being submitted, if they want to. Having a dedicated application that also does things like enable the reviewer to go through the fedora-review checklist quickly and accurately would make things much smoothe
Re: F27 System Wide Change: No More Alphas
On Mon, 2017-02-20 at 20:49 -0500, Neal Gompa wrote: > On Mon, Feb 20, 2017 at 7:24 PM, Adam Williamson > wrote: > > On Mon, 2017-02-20 at 18:24 -0500, Neal Gompa wrote: > > > I for one don't actually want Rawhide to be gated because it makes > > > things much harder in terms of properly developing new features. We're > > > simply not capable of being as good as OpenSUSE in terms of automation > > > to be able to pull off the feats they do. There were major changes to > > > how OpenSUSE did packaging to begin with to be able to pull off what > > > they did, and I simply don't think anyone here is prepared to do even > > > a small bit of that yet. > > > > This is vague and non-actionable. What, specifically, do you think will > > be a problem, and what, specifically, do you think needs changing to > > fix the problem? > > So, off the top of my head, there are a few things here: It seems a fundamental assumption in more or less all your points is that this process would involve Bodhi. But that's not a part of the proposal. Nothing in the proposal involves using Bodhi. > * We need actual post-build checks to occur right after the build, > using rpmlint and other tools. Right now, no one knows *anything* > about the usefulness of a package until we submit to Bodhi. This is not in fact the case. The Taskotron tests are run for every non-scratch build in Koji (AIUI). That includes all Rawhide builds; we already run all Taskotron tests for all Rawhide package builds, and packagers can see the results in the Taskotron web UI or sign up for FMN notifications. The most obvious place where you *see* the results at present is in the Bodhi web UI, but that's just because people often go look at that UI. All that's happening there is the Bodhi client-side Javascript is querying ResultsDB for all tests related to the packages in the update. But the tests were actually run as soon as the package build happened. > Some other nice-to-haves that should probably make our lives a bit easier: These are all interesting points but I really don't see any reason why they are particularly related to this proposal. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
El mar, 21-02-2017 a las 01:56 +0100, Ralf Corsepius escribió: > On 02/21/2017 01:48 AM, Kevin Fenzi wrote: > > On Tue, 21 Feb 2017 00:14:56 + > > "M. Edward (Ed) Borasky" wrote: > > ...snip... > > > > > > > > Rawhide as it currently exists can't stay solid enough for me > > > even > > > with just the few pieces I absolutely need. Tumbleweed, for all > > > it's > > > promise of "latest and greatest", is not supported by enough > > > third > > > parties to be useful even as just a host. And sid is, well, sid. > > > > I'm curious what issues you hit with Rawhide? Have any examples? > > Current rawhide (== Feb 15) does not match with what the builders > use. > => It's impossible to locally investigate runtime bugs > > Real world example: > https://bugzilla.redhat.com/show_bug.cgi?id=1425129 > Rawhide has been broken since the 15th, First due to nss, then rdma- core, followed by policycoreutils and setools breakages. it has taken a bunch of manual work to get it all figured out, cleaned up and composes kicked off, its exactly the types of breakages that I am trying to avoid by implementing the change. rawhide as it exists today will still exist i the buildsystem. Longer term I would like to extend things to do things like automatic rebuilds when we detect breakage. I am sure we are not going to get this perfect on day 1, but that over time we will improve and make it more and more useful. The goal is to make everyone life better. I have started looking at ways to make repos available for early testing and debugging problems in builds that have just been built for stable fedora's as well. We will have a repo of builds that have been built but not released. we will also be working to get notifications to developers quicker that a change they made, has broken things. Please do not assume that the reason why rawhide is currently a little stale is due to intentionally not pushing changes or holding anything back because it is not. It is entirely a matter of the type of breakage we want to avoid going forward, Dennis signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, Feb 20, 2017 at 4:50 PM Kevin Fenzi wrote: > On Tue, 21 Feb 2017 00:14:56 + > "M. Edward (Ed) Borasky" wrote: > ...snip... > > > > > Rawhide as it currently exists can't stay solid enough for me even > > with just the few pieces I absolutely need. Tumbleweed, for all it's > > promise of "latest and greatest", is not supported by enough third > > parties to be useful even as just a host. And sid is, well, sid. > > I'm curious what issues you hit with Rawhide? Have any examples? > It's been a while since I went through the exercise. For a while the Workstation Live media wasn't building and the GNOME desktop wasn't installing from the netinstall because LibreOffice wasn't working. More recently I hit some Fortran fallout from the GCC 7 mass rebuild. That would only be a problem if I was running host R, not R in a container. I suspect I'll be able to run my current workload including R on the F26 alpha without any problems. > > kevin > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- How many people can stand on the shoulders of a giant before the giant collapses? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, Feb 20, 2017 at 6:36 PM M. Edward (Ed) Borasky wrote: > It's been a while since I went through the exercise. For a while the > Workstation Live media wasn't building and the GNOME desktop wasn't > installing from the netinstall because LibreOffice wasn't working. More > recently I hit some Fortran fallout from the GCC 7 mass rebuild. That would > only be a problem if I was running host R, not R in a container. I suspect > I'll be able to run my current workload including R on the F26 alpha > without any problems. > Oh, yeah ... there are some issues with GNOME Wayland running in a Virtual Machine Manager VM on a GNOME Wayland host that I haven't had time to troubleshoot. I've gone back to X but at some point I need to dig into what's happening. But that's on F25 - maybe it's fixed in Rawhide. -- How many people can stand on the shoulders of a giant before the giant collapses? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity WG
Dear all, You are kindly invited to the meeting: Modularity WG on 2017-02-21 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting for the Modularity Working Group. More information available at: [Modularity Working Group wiki page](https://fedoraproject.org/wiki/Modularity_Working_Group) The agenda for the meeting is available at [modularity-wg-agendas pad](http://piratepad.net/modularity-wg-agendas). Source: https://apps.fedoraproject.org/calendar/meeting/5168/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, Feb 20, 2017 at 05:09:55PM -0700, Kevin Fenzi wrote: > On Mon, 20 Feb 2017 18:24:21 -0500 > Neal Gompa wrote: > > > On Mon, Feb 20, 2017 at 5:20 PM, Kevin Kofler > > wrote: > > > Dennis Gilmore wrote: > > >> I do not get what you mean by your statement, it is extremely vague > > >> with no detail. can you please expand on it in the context of the > > >> change? and the changes it will bring to the entire workflow of > > >> rawhide? > > > > > > Rawhide is just nowhere near working, half the packages have broken > > > dependencies due to not building with the latest GCC. > > Thats a bit over dramatic don't you think? > 968 currently on the FTBFS list, and even there many of those don't > have broken deps because the previous build still works. > > > If you really > > > implement your gating idea to "fix" that, this means the mass > > > rebuild (and the new GCC!) could NOT be tagged until ALL the broken > > > dependencies are fixed. That may take months. Or you freeze GCC > > > (and similar packages) on a fixed version forever and never upgrade > > > it again (kinda like in the old RHL 7.x days where that 2.96 > > > snapshot was kept even when 3.2 was current). If that (withholding > > > new compilers for months until all packages work with them) is not > > > the plan, then the gating will not do any good, because that is > > > where the breakage comes from, not updates of leaf packages. > > Yeah, the mass rebuild case will need to be excepted once it's "good > enough" or have some other way of landing... Hm, can you explain a bit more how that'd work? Let's say that there is a mass rebuild for any reason, and some packages are FTBFS, and we reached the point of "good enough". The side tag is merged back, but what happens with gating now? Various packages cannot be tested being their dependants are non-installable... How do we get back to the "clean" state? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Tue, 2017-02-21 at 03:49 +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Feb 20, 2017 at 05:09:55PM -0700, Kevin Fenzi wrote: > > On Mon, 20 Feb 2017 18:24:21 -0500 > > Neal Gompa wrote: > > > > > On Mon, Feb 20, 2017 at 5:20 PM, Kevin Kofler > > > wrote: > > > > Dennis Gilmore wrote: > > > > > I do not get what you mean by your statement, it is extremely vague > > > > > with no detail. can you please expand on it in the context of the > > > > > change? and the changes it will bring to the entire workflow of > > > > > rawhide? > > > > > > > > Rawhide is just nowhere near working, half the packages have broken > > > > dependencies due to not building with the latest GCC. > > > > Thats a bit over dramatic don't you think? > > 968 currently on the FTBFS list, and even there many of those don't > > have broken deps because the previous build still works. > > > > > If you really > > > > implement your gating idea to "fix" that, this means the mass > > > > rebuild (and the new GCC!) could NOT be tagged until ALL the broken > > > > dependencies are fixed. That may take months. Or you freeze GCC > > > > (and similar packages) on a fixed version forever and never upgrade > > > > it again (kinda like in the old RHL 7.x days where that 2.96 > > > > snapshot was kept even when 3.2 was current). If that (withholding > > > > new compilers for months until all packages work with them) is not > > > > the plan, then the gating will not do any good, because that is > > > > where the breakage comes from, not updates of leaf packages. > > > > Yeah, the mass rebuild case will need to be excepted once it's "good > > enough" or have some other way of landing... > > Hm, can you explain a bit more how that'd work? Let's say that there > is a mass rebuild for any reason, and some packages are FTBFS, and we > reached the point of "good enough". The side tag is merged back, but > what happens with gating now? Various packages cannot be tested being > their dependants are non-installable... How do we get back to the "clean" > state? An obvious initial option is to only 'gate' on (some definition of) 'core' packages - critpath packages, packages in the base 'module', whatever definition we want to use. We'd only care if *those* packages passed all tests. I actually wasn't that focused on the package-level testing aspect of this proposal. I'm much more interested in the idea of whether Rawhide 'works' in the sense of passing functional tests (i.e., at present, the openQA and Autocloud tests). I'm actively working on setting things up such that a single ResultsDB query for each compose will answer the question of whether it passes all the critical smoke tests, or all the Alpha tests, or all the Beta tests, etc. On that path, of course, only packages involved in the test level we choose to gate on (presumably 'critical' or 'Alpha' at first) need to work. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Monday, February 20, 2017 6:44:50 PM CET Jan Kurik wrote: > Fedora will no longer produce Alpha releases. As a side-effect of making rawhide "alpha". That doesn't sound bad. After seeing Denis's talk on devconf, I think I understand the motivation: it takes ages to generate all the Fedora related products like images. Right? > == Detailed Description == > By gating Rawhide builds from landing in the compose and gating the > publication of composes on automated test results we will ensure Rawhide will > always be at Alpha quality. This will make it more generally useful to people > as a daily driver and development platform, and mean we no longer need to go > through the process of building, testing and shipping Alpha releases. The > initial testing will be ensuring that a package is installable and that it > does not break existing packages installation. Ok, I'm curious why we'll treat CI/testing differently on stable releases and on fedora. AFAIK, _bodhi_ runs the tests for stable releases, and for Rawhide it will be koji directly? Why you don't move all the testing to koji then? From this perspective, this sounds like we invent sub-optimal (release engineering) and confusing (for packager's) workflow. > Over time we can enable extra testing to gate the build going into > rawhide. Builds will land in the buildroot to be built against before > they make it to the compose. It is not specified, but there will be two sets of tests? One to even move the package to buildroot to build against, and second to move the package to rawhide repo, right? Then what about to do apply the same process for updates-testing? Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: No More Alphas
On Mon, Feb 20, 2017 at 05:48:58PM -0700, Kevin Fenzi wrote: > On Tue, 21 Feb 2017 00:14:56 + > "M. Edward (Ed) Borasky" wrote: > ...snip... > > > > > Rawhide as it currently exists can't stay solid enough for me even > > with just the few pieces I absolutely need. Tumbleweed, for all it's > > promise of "latest and greatest", is not supported by enough third > > parties to be useful even as just a host. And sid is, well, sid. > > I'm curious what issues you hit with Rawhide? Have any examples? I have: page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page)), kernel BUG at include/linux/page-flags.h:275 https://bugzilla.redhat.com/show_bug.cgi?id=1303860 Because of this bug, I haven't been able to start GDM on my Rawhide box *for a year* now. -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20170220.n.2 compose check report
Missing expected images: Atomic qcow2 x86_64 Server dvd i386 Workstation live i386 Kde live x86_64 Xfce raw-xz armhfp Server boot i386 Atomic raw-xz x86_64 Workstation live x86_64 Kde live i386 Failed openQA tests: 11/85 (x86_64), 1/2 (arm) ID: 57160 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/57160 ID: 57162 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/57162 ID: 57165 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/57165 ID: 57178 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/57178 ID: 57202 Test: x86_64 universal install_rescue_encrypted URL: https://openqa.fedoraproject.org/tests/57202 ID: 57205 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/57205 ID: 57219 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/57219 ID: 57221 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/57221 ID: 57226 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/57226 ID: 57232 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/57232 ID: 57233 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/57233 ID: 57237 Test: x86_64 universal install_rescue_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/57237 Soft failed openQA tests: 49/85 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 57152 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/57152 ID: 57153 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/57153 ID: 57154 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/57154 ID: 57161 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/57161 ID: 57170 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/57170 ID: 57172 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/57172 ID: 57173 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/57173 ID: 57180 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/57180 ID: 57181 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/57181 ID: 57182 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/57182 ID: 57183 Test: x86_64 universal install_delete_pata URL: https://openqa.fedoraproject.org/tests/57183 ID: 57184 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/57184 ID: 57185 Test: x86_64 universal install_sata URL: https://openqa.fedoraproject.org/tests/57185 ID: 57186 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/57186 ID: 57187 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/57187 ID: 57188 Test: x86_64 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/57188 ID: 57189 Test: x86_64 universal install_multi URL: https://openqa.fedoraproject.org/tests/57189 ID: 57190 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/57190 ID: 57191 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/57191 ID: 57192 Test: x86_64 universal install_simple_free_space URL: https://openqa.fedoraproject.org/tests/57192 ID: 57193 Test: x86_64 universal install_multi_empty URL: https://openqa.fedoraproject.org/tests/57193 ID: 57194 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/57194 ID: 57195 Test: x86_64 universal install_delete_partial URL: https://openqa.fedoraproject.org/tests/57195 ID: 57196 Test: x86_64 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/57196 ID: 57197 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/57197 ID: 57198 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/57198 ID: 57199 Test: x86_64 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/57199 ID: 57200 Test: x86_64 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/57200 ID: 57201 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/te
Re: F27 System Wide Change: No More Alphas
On Tue, 2017-02-21 at 07:43 +0100, Pavel Raiskup wrote: > On Monday, February 20, 2017 6:44:50 PM CET Jan Kurik wrote: > > Fedora will no longer produce Alpha releases. > > As a side-effect of making rawhide "alpha". That doesn't sound bad. > > After seeing Denis's talk on devconf, I think I understand the motivation: > it takes ages to generate all the Fedora related products like images. > Right? Well, yes, it does, but that's not so much a *motivation* for this as one of the factors that complicates the implementation. The motivation is simply to have a better quality product. > > == Detailed Description == > > By gating Rawhide builds from landing in the compose and gating the > > publication of composes on automated test results we will ensure Rawhide > > will > > always be at Alpha quality. This will make it more generally useful to > > people > > as a daily driver and development platform, and mean we no longer need to go > > through the process of building, testing and shipping Alpha releases. The > > initial testing will be ensuring that a package is installable and that it > > does not break existing packages installation. > > Ok, I'm curious why we'll treat CI/testing differently on stable releases > and on fedora. AFAIK, _bodhi_ runs the tests for stable releases, and for > Rawhide it will be koji directly? Why you don't move all the testing to koji > then? Neither Bodhi nor Koji runs any tests (except for the %check section of a package build, I guess). The package tests are run by Taskotron. Right now they are run for every Koji build, but adjusting the triggers is fairly trivial, if we want to trigger the tests in any other way. You can see the trigger code at https://pagure.io/taskotron/taskotron-trigger/blob/develop/f/jobtriggers . You can *see* the test results from the Bodhi web interface, but that doesn't mean Bodhi is running the tests or really that the tests have anything to do with Bodhi. That's just Bodhi's client-side Javascript querying ResultsDB for any test results marked as being related to the packages in the update. (Out of interest, if I manage to get my current side project of having openQA run tests on critpath updates up and running, those results will just 'magically' show up in Bodhi as well, since all Bodhi is doing is querying ResultsDB). > It is not specified, but there will be two sets of tests? One to even > move the package to buildroot to build against, and second to move the > package to rawhide repo, right? Then what about to do apply the same > process for updates-testing? There are already quite a lot of plans in place relating to this. Bodhi is only one possible integration point for tests. The major focus at present is to deploy a Pagure instance on top of dist-git, as that provides another point at which we can provide a proper test feedback loop. Right now, we already run package tests on every Koji build and we could in theory run package tests on every git commit (as we know when dist-git commits happen), but there is no system through which can do any kind of useful feedback loop or gating based on the results. Pagure-for-dist-git would provide that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
