Re: About to orphan FreeGLUT
All right. You were the only one interested in taking FreeGLUT. It should be yours now. Thank you. --ts On Tue, 17 Sep 2019 18:10:21 + Gwyn Ciesla via devel wrote: > Happy to have you. :) > > > -- > Gwyn Ciesla > she/her/hers > > in your fear, seek only peace > in your fear, seek only love > -d. bowie > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, September 17, 2019 1:09 PM, Adam Jackson > wrote: > > > On Tue, 2019-09-17 at 15:12 +, Gwyn Ciesla via devel wrote: > > > > > > I'd love to see this not go away. If you can't find another volunteer > > > before you orphan, I'll take it, FAS: limb. If someone with more > > > experience with it steps up, give it to them. > > > > > I can't have mesa-demos break so I'm happy to comaintain. > > > > > - ajax > -- Tomáš Smetana OpenShift Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
About to orphan FreeGLUT
Hello, I'm currently maintaining FreeGLUT: there's a new version out (3.2.0) which brought ABI incompatibilities. There are also new things like Wayland support which I think might be interesting for someone to test and enable in Fedora eventually. I simply don't have time for this any more. Let me know if you're interested. I'll orphan FreeGLUT by the end of the week. Regards, -- Tomáš Smetana OpenShift Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Retiring Gnomebaker
Hello. I maintain one of the old CD-burning GUIs in Fedora: Gnomebaker. It served me well until Fedora 30 but the upstream is inactive for quite some time... The Gnomebaker dependencies disappeared in F31 (gstreamer-0.10) and porting the code to the new libraries is not worth the effort for me. It's unlikely but if there was somebody willing to rewrite the code and maintain the package, let me know. Otherwise: Gnomebaker is to be retired. Regards, -- Tomáš Smetana OpenShift Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning xcdroast
Hello, I have orphaned the xcdroast package, feel free to take it or let it die. It should be rebased but since the upstream version relies on the original CDDL-licensed cdrtools there will always be some undroppable patches required I'm afraid. Regards, -- Tomáš Smetana OpenShift Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, 2 Sep 2016 13:14:13 +0200 Igor Gnatenko <ignate...@redhat.com> wrote: > * Package replacement > Package "storaged" has "Obsoletes: udisks2" -> take latest version > from koji (2.1.7-1) and make Obsoletes versioned: udisks2 < 2.1.7-2 > storaged is not simple use-case as it replaces udisks2, but latter is > still not retired. Followed your advice, should be fixed soon in Rawhide and F25. Thanks and regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F25 change update: new storaged just landed in Rawhide
On Wed, 13 Jul 2016 08:43:33 -0500 Michael Catanzaro <mcatanz...@gnome.org> wrote: > On Wed, 2016-07-13 at 11:43 +0200, Tomáš Smetana wrote: > > Hello, > > Just a heads-up: I have just build the 2.6.2 version of storaged > > that should > > replace udisks2 in Fedora 25. The upgrade should be seamless: Cockpit > > and > > Blivet would need to be rebuilt too to use the new API. The rest of > > the system > > should just work as usually. > > > > Thanks and regards, > > I've you've verified that rawhide still works after the udisks2 package > is removed, then I can retire udisks2. Are we ready for that? I think > there's no point in keeping it around in Fedora anymore. Hi, udisks2 is part of the "contingency plan" so please keep it around for a while. However you're right that udisks2 is now obsolete and there is no need to maintain it in Fedora. Thanks and regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F25 change update: new storaged just landed in Rawhide
Hello, Just a heads-up: I have just build the 2.6.2 version of storaged that should replace udisks2 in Fedora 25. The upgrade should be seamless: Cockpit and Blivet would need to be rebuilt too to use the new API. The rest of the system should just work as usually. Thanks and regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F25 Self Contained Change: Replace UDisks2 by Storaged
Hello. On Fri, 13 May 2016 15:49:45 -0400 Stephen Gallagher <sgall...@redhat.com> wrote: > On 05/13/2016 03:34 PM, Michael Catanzaro wrote: > > On Fri, 2016-05-13 at 13:01 -0400, Stephen Gallagher wrote: > >> CCing the desktop list, but please keep replies on the Fedora devel > >> list. > >> > >> > >> At today's FESCo meeting[1], we raised several questions that we > >> would like to > >> have answered about this change. > >> > >> 1) Have the GNOME, Anaconda/Blivet and Cockpit folks agreed to > >> replacing Udisks2? As for Gnome: I think this has been sorted out -- as long as we don't break anything, nobody seems to have strong opinions about udisks2 vs storaged. Anaconda/Blivet has never been the udisks2 API consumer: the storaged dependency has been added for iSCSI support that was never present in udisks2. > >> 2) Is it expected to be a complete cutover (where we drop Udisks2 > >> from the > >> default install and/or from the distro entirely The plan for storaged is to provide complete udisks2 API drop-in replacement: the dependent components should not notice. Once there is nothing requiring udisks2 itself there is no need to keep it in the distribution... > > udisks upstream is inactive and has recently expressed some interest in > > allowing the storaged developers to take over maintenance of udisks > > going forward. It would be better to first try merging the storaged > > changes into udisks instead; that way, we share the same code across > > all distros, without having to evangelize storaged vs. udisks. > > With respect, the reason storaged exists is because Udisks2 upstream > refused to accept patches to support LVM. I'm not saying we shouldn't try > to merge them back together, but the fork happened because upstream was > obstinate. Merging the code and joining forces would be of course the best way forward. I wouldn't care about the name of the result. > To the best of my knowledge (Tomas Smetana can correct me), storaged is a > proper superset (and has a more encompassing name), so my suggestion would > be to just make storaged the official upstream and migrate away from the > older Udisks2. (With a plan to deprecate the org.freedesktop.Udisks2 > interface in 2-3 years in favor of the org.storaged.Storaged interface). There is no plan to deprecate the org.freedesktop.Udisks2 interface yet. And if the two projects merge again it's perhaps better to keep the old naming so the API consumers don't have to suffer unnecessary changes. The more important tasks for storaged would be improving scalability, adding more automated tests (especially for the new stuff), packaging for Debian/Ubuntu, etc... Regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F25 Self Contained Change: Replace UDisks2 by Storaged
On Fri, 15 Apr 2016 05:09:00 -0400 (EDT) Bastien Nocera <bnoc...@redhat.com> wrote: > Hey, ... > What are the additional dependencies compared to Udisks2? None AFAIK: storaged itself should not pull anything else than udisks2 in the current Rawhide. > Would gnome-disk-utility, gvfs, etc. work as well as they used to without > regressions when dropping in storaged, either on a running system, or when > compiling against it? Yes, such is the plan. > Will bug fixes and enhancements to the common part between storaged and > udisks2 be backported to udisks2? I assume this is a question for the udisks2 developers. > I'm fairly certain we don't want iSCSI binaries in the Workstation > installation (we've been trying to get rid of the ones that Anaconda brings > in already). > > I also don't see why ZRam is something 1) you'd want to have to configure, > 2) that has its place in a storage API. It's been put to the API because Blivet would like to use it from storaged eventually. However you're right: this is something that the user may not want to install and therefore the storaged-zram is a separate package. Same as LSM, LVM2, iSCSI, bcache and BTRFS plugins. Of course the plugins have their own additional dependencies. Regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
C++ preprocessor behaviour change in rawhide
Hello, one of my packages (tvtime) failed to build during the mass rebuild. Not a big deal, I think there are several ways to fix it. The odd thing is that the build failed due to a rather unexpected change in C++ preprocessor (g++ -E or cpp). Let's assume I have a test.cpp file containing this: #define MYMACRO(a, b) ""a", "b"" MYMACRO(x,y) Now `cpp test.cpp' (or `g++ -E test.cpp') on rawhide produces: # 1 "test.cpp" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "test.cpp" ""a", "b"" However on F23 or with `cpp -std=gnu++98 test.cpp' (`g++ -std=gnu++98 -E test.cpp') I got: # 1 "test.cpp" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "test.cpp" ""x ", "y "" Is this something known/documented? Or should I file a bug? I found this behaviour rather strange (but so are the macros in tvtime...). Thanks and regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: C++ preprocessor behaviour change in rawhide
On Wed, 10 Feb 2016 17:38:08 +0100 Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Feb 10, 2016 at 05:27:46PM +0100, Tomáš Smetana wrote: > > Hello, > > one of my packages (tvtime) failed to build during the mass rebuild. > > Not a big deal, I think there are several ways to fix it. The odd thing > > is that the build failed due to a rather unexpected change in C++ > > preprocessor (g++ -E or cpp). > > > > Let's assume I have a test.cpp file containing this: > > > > #define MYMACRO(a, b) ""a", "b"" > > MYMACRO(x,y) > > > > Now `cpp test.cpp' (or `g++ -E test.cpp') on rawhide produces: > > That is expected, and in F23 you get the same behavior if you use > -std=c++11 or -std=c++14. Yup. This part is obvious... :) > In C++11 and later the language has user defined literals, so if you just > want to concatenate strings, you need to put a whitespace in between them, > otherwise the preprocessor considers ""a as user defined literal, similarly > for ", "b and that is why it is not macro expanded. > Just use > #define MYMACRO(a, b) "" a ", " b "" OK. Thanks a lot for the explanation. Regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat
On Wed, 13 Jan 2016 14:38:08 +0100 Florian Festi <ffe...@redhat.com> wrote: > On 01/13/2016 02:36 PM, Reindl Harald wrote: > > > > > > Am 13.01.2016 um 14:30 schrieb Richard Hughes: > >> On 13 January 2016 at 13:13, Reindl Harald <h.rei...@thelounge.net> > >> wrote: > >>> so there is no justification to declare one need to install from scratch > >>> just because rpm which works for many years fine changes it's storage > >>> format > >> > >> I don't think anyone said there was a need to reinstall from scratch > > > > so how do you translate "clearly not forward compatible"? > > "forward compatible" means the old version of a program being able to > read/process newer version data. > > The current rpm versions will not be able to read the new database format. I tend to use systemd-nspawn containers for building rpms. So for example, I have a Fedora 24 system and use its dnf to create e.g. Centos 7 container root and then build Centos rpms from within that container. If I understand the change correctly, this is going to break since the Centos 7 rpm-build will not be able to read the database created by the Fedora 24 dnf. I know more people using dnf/rpm to "manage" the containers and this is somewhat a regression for us. I'm not sure there is a way to prevent this breakage... So just FYI. :) Thanks and regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [ACTION REQUIRED] FTBFS Packages in rawhide (2015-07-08)
On Wed, 8 Jul 2015 21:55:06 + (UTC) opensou...@till.name wrote: The following packages did not build for two releases and should be retired when Fedora (F23) is branched, unless someone takes care of them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life According to https://fedoraproject.org/wiki/Schedule branching will occur on 2015-07-14. The packages might be retired shortly before this. Package(co)maintainers Status Change === ... gnomebaker tsmetana, hadrons123 60 weeks ago This should be fixed now. It was my silly omission in one of the previous fixes... Regards, -- Tomáš Smetana Platform Engineering, Red Hat -- 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: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On Fri, 6 Mar 2015 14:11:03 +0100 Michael Schwendt mschwe...@gmail.com wrote: On Fri, 06 Mar 2015 12:49:12 +0300, Pavel Alexeev wrote: Hello. ImageMagick itself built in rawhide. just go ahead an rebuild pfstools, please. I'll intervene only in the case something goes wrong. First attempt fails [1] with: pfsinimgmagick.opfsoutimgmagick.o: : InIn functionfunction ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/ BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/ pfsoutimgmagick.cppundefined: 194:reference undefined toreference `to Magick`:Magick:::ImageImageImage(Imageunsigned( intstd,: :unsigned __cxx11int:,: stdbasic_string::__cxx11char:,: basic_stringstdchar:, :std:char_traits:char_traitscharchar, , stdstdallocatorallocatorcharchar const ,const MagickCore):': StorageType, void const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198: undefined reference to `Magick::Image::write(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is: /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to `Imf_2_2::TypedAttributestd::string::staticTypeName()' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30): undefined reference to `Imf_2_2::TypedAttributestd::string::writeValueTo(Imf_2_2::OStream, int) const' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38): undefined reference to `Imf_2_2::TypedAttributestd::string::readValueFrom(Imf_2_2::IStream, int, int)' Right now unsure how to handle it. But I continue digging. [1] https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/build.log [2] http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ It wasn't build with your upgrade, but an older one: https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/root.log DEBUG util.py:388: ImageMagick i686 6.8.8.10-7.fc22 build 159 k DEBUG util.py:388: ImageMagick-c++ i686 6.8.8.10-7.fc22 build 167 k DEBUG util.py:388: ImageMagick-libsi686 6.8.8.10-7.fc22 build 2.0 M You may need to look into using koji wait-repo … to give koji some time to recreate the buildroot repo metadata after including a new build. It may take roughly up to 20 minutes for a build to be included. Meanwhile, the buildroot should be up-to-date, so give it another try. Thanks. You were faster... I'm also afraid the example above shows building only the ImageMagick direct dependencies might not be sufficient. Seems that right now there are some packages that have been rebuilt with gcc-5 and some not yet. This may lead to more linker failures when one binary wants to link with several libraries with incompatible ABIs... Regards, -- Tomáš Smetana Platform Engineering, Red Hat -- 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: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On Fri, 06 Mar 2015 12:49:12 +0300 Pavel Alexeev fo...@hubbitus.com.ru wrote: Hello. ImageMagick itself built in rawhide. pfsinimgmagick.opfsoutimgmagick.o: : InIn functionfunction ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/ BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/ pfsoutimgmagick.cppundefined: 194:reference undefined toreference `to Magick`:Magick:::ImageImageImage(Imageunsigned( intstd,: :unsigned __cxx11int:,: stdbasic_string::__cxx11char:,: basic_stringstdchar:, :std:char_traits:char_traitscharchar, , stdstdallocatorallocatorcharchar const ,const MagickCore):': StorageType, void const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198: undefined reference to `Magick::Image::write(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status ... But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is: /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to `Imf_2_2::TypedAttributestd::string::staticTypeName()' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30): undefined reference to `Imf_2_2::TypedAttributestd::string::writeValueTo(Imf_2_2::OStream, int) const' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38): undefined reference to `Imf_2_2::TypedAttributestd::string::readValueFrom(Imf_2_2::IStream, int, int)' Right now unsure how to handle it. But I continue digging. Hi, thanks for the effort... I'll see if I could do something about this. Regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaned cleanfeed
Hello, the package cleanfeed is now orphaned. There are no comaintainers: Feel free to take it. Thanks and regards, -- Tomáš Smetana Platform Engineering, Red Hat -- 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: rawhide report: 20120909 changes
On Sun, 9 Sep 2012 12:39:46 + Fedora Rawhide Report rawh...@fedoraproject.org wrote: [freeglut] freeglut-devel-2.8.0-7.fc19.i686 requires libGLU-devel freeglut-devel-2.8.0-7.fc19.x86_64 requires libGLU-devel Hello, freeglut is mine and I wonder whether the new mesa-libGLU package misses the Provides: libGLU-devel on purpose or if it was just an omission. Thanks and regards, -- Tomáš Smetana -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120909 changes
On Mon, 10 Sep 2012 08:30:03 -0400
Rich Mattes richmat...@gmail.com wrote:
Looks like it was also reported in its own bug (
https://bugzilla.redhat.com/show_bug.cgi?id=855536). There's a new build
at (http://koji.fedoraproject.org/koji/buildinfo?buildID=353410) which has
the libGLU{,-devel} provides.
...which answers my question. I should have searched the Bugzilla first.
Thanks for the link.
Regards,
--
Tomáš Smetana
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
On Sun, 27 May 2012 23:28:03 +0400 Pavel Alexeev fo...@hubbitus.com.ru wrote: Hi. Due to the security issues ([1] for example) and act as newcomer provenpackager I'll plan update ImageMagick in Fedora 16 too (I should had been done it early off course). It seams addressed in rawhide. Hello, may I ask why you prefer bumping the soname instead of just patching the vulnerabilities? The patch is actually ready. Replacing the library with an ABI incompatible version in the stable Fedora release sounds like an overkill in this case. Thanks and regards, -- Tomáš Smetana -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-17
Hello, I've taken these: pfscalibration pfstmo pfstools I do use them occasionally but I know nothing about their internals. I just don't want those packages to be purged out of Fedora. I will happily pass them to somebody else or welcome any co-maintainers. Regards, -- Tomáš Smetana Base OS Engineering Supervisor, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
