Re: Retiring v8-314
> Hey, remember when I said I would keep v8-314 alive? I've changed my mind.
> C) It doesn't build anymore because the giant SConstruct goop it uses is
> not compatible with the current SCons. (and it has not built for quite a
> while now).
> D) I have neither the time nor the motivation to do the work to make it
> build again
I've managed to make it build with this simple patch, not sure if everything is
correct though in regards to options.
--- SConstruct.old 2012-10-22 15:09:53.0 +0200
+++ SConstruct 2019-03-15 19:53:49.595494085 +0100
@@ -1183,7 +1183,7 @@ def AddOptions(options, result):
def GetOptions():
- result = Options()
+ result = Variables()
result.Add('mode', 'compilation mode (debug, release)', 'release')
result.Add('sample', 'build sample (shell, process, lineprocessor)', '')
result.Add('cache', 'directory to use for scons build cache', '')
___
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: Retiring v8-314
Hi Tom, What do you suggest to packages that depends on this library, bundle or retire as well? Thanks, Samuel ___ 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: /etc/yum.repos.d -> /etc/distro.repos.d
> If anything of the like, /etc/dnf.repos.d makes more sense. These repos are > not > necessarily part of the distro. Please don't tie the name with the particular software to avoid this issue in the future. If you must then I think rpm.repos.d is less likely to avoid this issue in the future. ___ 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: No builds of v8-314 for f30 and f31
> You may have the answer here: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... > and here: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... The threads are about v8 which is a different case. I am asking if someone is currently working on v8-314. Or could we make libreadline.so.7 available for compatibility? Thanks. ___ 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
No builds of v8-314 for f30 and f31
Hello, I am wondering what is the status of v8-314. In koji there are some failed builds for f30. New builds are required because readline was updated to a new version, thus Fedora 29 version is not able to install. Error: nothing provides libreadline.so.7()(64bit) needed by v8-314-3.14.5.10-13.fc29.x86_64. ___ 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
dxflib ABI changed yet nothing changed
Hi, Got via e-mail that libdxflib's ABI changed in comparison to previous release, yet nothing changed in the package except version bump for the mass rebuild. Why is that? Digest Summary: 1. dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 2. dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 --- (2019-02-04 05:48:12 UTC) dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 - https://taskotron.fedoraproject.org/artifacts/all/f7d968de-26bc-11e9-a292-525400fc9f92/tests.yml/libdxflib-3.17.0-8.fc30.log dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 --- (2019-02-04 05:48:16 UTC) dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 - https://taskotron.fedoraproject.org/artifacts/all/f7c055d8-26bc-11e9-9451-525400fc9f92/tests.yml/libdxflib-3.17.0-8.fc30.log dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 ___ 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: Camotics fails with default Fedora flags GCC9 (cbang)
> On Sat, Feb 2, 2019 at 7:02 AM Samuel Rakitničan < > srakitnican(a)fedoraproject.org> wrote: > > > $ rpm -E %optflags > -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection > > The only required one seems to be for "format-security"... Right, -Werror is added by build script with debug option turned on that I forgot about. Sorry for the noise. > Thanks, > Richard ___ 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: Camotics fails with default Fedora flags GCC9 (cbang)
> On Sat, Feb 02, 2019 at 08:57:42AM -0000, Samuel Rakitničan wrote: > > Guess the important question is, is the warning correct or not? > If it is correct, certainly fix the code, if it is a false positive, either > find a workaround, turn the warning off (locally or globally) or don't build > wiht -Werror (or turn the particular warning into a warning only, say > -Werror -Wno-error=whatever). Warnings do have false positives and with > -Werror you need to be prepared to work around the warnings any time new > ones appear, typically -Werror is a good fit only for some projects and only > for development builds. The easiest would be to just disable -Werror because it doesn't help me personally. Not sure if that is allowed by Fedora Packaging guidelines, though. ___ 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
Camotics fails with default Fedora flags GCC9 (cbang)
Hi, With a new version of GCC errors are blocking the build at various places. Not sure how serious the issue is. Should I just add the compiler flags to get through the build? Upstream issue: https://github.com/CauldronDevelopmentLLC/cbang/issues/29#issuecomment-459673777 ___ 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: /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory
> https://bugzilla.redhat.com/show_bug.cgi?id=1657356 > > Adam Jackson, the Mesa maintainer in Fedora, has been on vacation, getting > back tomorrow, so should take care of it then, if nobody fixes it first. > > Including mesa-libEGL-devel as a buildrequire is a harmless workaround, but > certainly shouldn't be necessary I'll wait for the bug resolution, thanks! > > Owen ___ 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: /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory
> Hmm on a second look mesa-libGL-devel seems to be installing judging by > root.log. File is > missing for some reason? Please disregard, I've mixed up mesa-libEGL-devel with mesa-libGL-devel. So mesa-libEGL-devel is not pulled anymore for some reason. The original question still stands. ___ 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: /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory
Hmm on a second look mesa-libGL-devel seems to be installing judging by root.log. File is missing for some reason? ___ 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
/usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory
Hi, Got an e-mail from Koschei [1] with a notice that camotics package is starting to fail to build. The reason for this seems to be that something that used to pull mesa-libEGL-devel doesn't do so anymore. /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory Since /usr/include/GL/glext.h belongs to mesa-libGL-devel and not camotics I think it would be more appropriate to put the dependency there. Thoughts? [1] https://apps.fedoraproject.org/koschei/package/camotics?collection=f29 ___ 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: Fedora Lifecycles: imagine longer-term possibilities
> As can be clearly seen from the breadth of the update streams, once F+2 > is released, F+1 still gets a moderate number of updates, but F only > gets major bugs fixed, at best. Some maintainers care more, some less, > but it's pretty obvious that our "oldstable" release is not where the > maintainers are. Now imagine how well we would support F-4 (36 months) > or F-6 (48 months). I'd guess "not at all". > > I don't see this going anywhere without a lot of new maintainers. > > Zbyszek How about keeping the number of supported releases the same, just change the support window for them. For example have one release that is supported for 6 months, and then have one release that is supported for longer. ___ 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: [SO-NAME BUMP] libjson-c.so.4 comes to fc28 and Rawhide
Hi, It seems bti was missed from this so bump and it is currently broken. The koji build[1] was deleted and there is nothing in bodhi [2]. [1] https://koji.fedoraproject.org/koji/...packageID=6699 [2] https://bodhi.fedoraproject.org/updates/?packages=bti ___ 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: Testing / feedback request: DNF 3 crashes
The following bug have not been updated since report. I would say it is a big issue since an upgrade will break dnf, https://bugzilla.redhat.com/show_bug.cgi?id=1598590 ___ 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: dnf history - change in how rpmdb checksum is computed
> If a user migrates from RHEL 7 to the next version of RHEL (or CentOS), > there will be continuity in used algorithm and history db checksums. > It's important to some enterprise customers to keep the history db in a > good shape. > Fedora users don't care about that much in general. I care about maintaining dnf history in Fedora, it is a very useful debugging tool. Seems like it is broken in rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=1598590 Is the hash reason why dnf 1/2 history doesn't work with dnf 3? ___ 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/message/JJ4TGQNYLX5X2ESSXQD66WKWK5652AIA/
Re: Kernel marking files in /boot as %ghost
> On Fri, Mar 2, 2018 at 1:11 AM, Samuel Rakitničan > > What is the result you expect from this email? You filed a bug, it > was closed because the packaging was done intentionally and there is > no other solution when considering the original reasons for the > change. But what are the original reasons exactly? Seems like those files are used by rpm-ostree. Fedora until this date still uses rpm as a default package manager and I don't see why they need to be present by default. Especially because: 1. Wasting space when installed 2. Breaking rpm feature And I don't see the benefits of doing so. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Official archiver of Fedora mailing lists shows e-mails with one day delay!
> I am one happy user of Spinics too. I find HyperKitty interface slow and > buggy. The only > way I am using HyperKitty is to post a message, and every time I find some > issue which I > have to go to a report process first. For example right now HyperKitty is not > displaying > comments of this thread for me, so to reply to a message I have to copy it > from spinics to > reply to it. > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... > > Reported the issue here: > https://pagure.io/fedora-infrastructure/issue/6759 > > There is also an issue with quotation where is taking the reply header from a > previous > poster. I just delete that header. Also, I like the basic HTML feature of visited URLs colored in different color to indicate messages that I've already read, something which HyperKitty does not have. I have to point out that showing messages is one of the basic features of an archiver and HyperKitty is not doing a very good job at it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Official archiver of Fedora mailing lists shows e-mails with one day delay!
> Sure Hyperkitty has drawbacks. Pipermail had drawbacks you complained > about too. You seem to win either way because you can complain if we > don't change stuff, and you can complain if we do change things. It is > really extremely tiring trying to deal with your constant > negativity... so I am going to stop doing so. I am one happy user of Spinics too. I find HyperKitty interface slow and buggy. The only way I am using HyperKitty is to post a message, and every time I find some issue which I have to go to a report process first. For example right now HyperKitty is not displaying comments of this thread for me, so to reply to a message I have to copy it from spinics to reply to it. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UQ42U25FVNEEVHLHQHYQ46W65USIM4PE/ Reported the issue here: https://pagure.io/fedora-infrastructure/issue/6759 There is also an issue with quotation where is taking the reply header from a previous poster. I just delete that header. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Kernel marking files in /boot as %ghost
> What is the result you expect from this email? You filed a bug, it was closed because the packaging was done intentionally and there is no other solution when considering the original reasons for the change. I'm not sure if you want the original change reverted entirely or what you would like to see, but "I don't like this" isn't really productive. Also, using rpm -qV as an indication that kernel installation is correct and bootable is simply never going to work anyway. The initramfs is generated at kernel installation time, and therefore has to be marked as %ghost. If that is missing, your machine doesn't boot with that kernel. If the grub config file doesn't get updated, your machine doesn't boot with that kernel. Not having initramfs or grub updated because of scriptlets not executing is expected, kernel image and configuration files etc. are however not. I am hoping for a discussion on how to potentially do this better without working around important rpm features. > What suggestion do you have for a solution? Stating the obvious, but why not install files to /boot in the first place as it was before. It seems the only logical thing to do until grub and other utilities learn how to read from other places. Also it seems like I am not the right person to answer that question since I still don't understand what are the benefits of having these files installed to /usr/lib/modules and also having them installed by default? If I understand correctly the only purpose they serve is to copy them back to /boot from some kind of /usr system image when restoring the system. This doesn't seem to me as a reason to install them by default in /usr in the first place. How about installing the files to /boot by default and making an optional subpackage named something like "kernel-stateless" with copies of these files. That way whatever needs its presence can depend on this subpackage. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Kernel marking files in /boot as %ghost
Dear list, I've stumbled upon a serious issue that has not been discussed before. Somewhere around May 2015 kernel files was moved to /usr/lib/modules/, which are then copied to /boot in post scriptlets [1]. The issue is that such files are marked with %ghost because they don't exist initially and are being copied when installed. Now because of that rpm (rpm -qV) can't verify the files attributes correctly and heck even doesn't point out if they don't exist at all as it is the case if dnf fails in the middle of transaction. Because of that I've opened a bug report [2], but it was closed because that was supposedly intended, but looking at mailing list archive, I don't see this particular issue being raised and frankly in my opinion marking files that are responsible to boot the system as %ghost should not happen. %ghost should be used only when there is not any other option left in case when files truly doesn't exist and its integrity could not be verified in advance. [1] https://lists.fedoraproject.org/pipermail/kernel/2015-May/005819.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1467450 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCC 8: camotics fails to build for i686, ARMv7 arches (reading 31 bytes from a region of size 16)
> It means the package should probably not be using -Werror Oh yes forgot that upstream forces -Werror. For now I will keep upstream preference as long as the issues reported gets fixed. All the reported issues was fixed upstream and the package built successfully for Fedora 28. Thank you for looking at it! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
GCC 8: camotics fails to build for i686, ARMv7 arches (reading 31 bytes from a region of size 16)
Hello, Need help figuring this out since I have no idea what this means. The cbang code that is included in camotics fails to build with the following messages. It is failing only for i686 and armv7hl architectures. g++ -o build/cbang/log/Logger.o -c -std=c++11 -ggdb -Wall -Werror -I/usr/include/v8-3.14/ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -Wno-error=parentheses -Wno-deprecated-declarations -DDEBUG -D_REENTRANT -DHAVE_EXPAT -DHAVE_PTHREADS -DHAVE_LIBSQLITE -DHAVE_V8 -DDEBUG_LEVEL=1 -DUSING_CBANG -Iinclude -Isrc -Isrc/boost src/cbang/log/Logger.cpp In file included from /usr/include/string.h:494, from src/boost/boost/range/detail/implementation_help.hpp:18, from src/boost/boost/range/end.hpp:24, from src/boost/boost/range/functions.hpp:19, from src/boost/boost/range/iterator_range_core.hpp:38, from src/boost/boost/range/iterator_range.hpp:13, from src/boost/boost/iostreams/traits.hpp:38, from src/boost/boost/iostreams/detail/dispatch.hpp:17, from src/boost/boost/iostreams/flush.hpp:17, from src/boost/boost/iostreams/close.hpp:18, from src/boost/boost/iostreams/operations.hpp:16, from src/cbang/http/ChunkedStreamFilter.h:41, from src/cbang/http/Transaction.h:37, from src/cbang/http/Transaction.cpp:33: In function 'void* memcpy(void*, const void*, size_t)', inlined from 'std::streamsize cb::HTTP::ChunkedStreamFilter::write(Sink&, const char*, std::streamsize) [with Sink = boost::iostreams::detail::linked_streambuf >]' at src/cbang/http/ChunkedStreamFilter.h:131:19, inlined from 'static std::streamsize boost::iostreams::detail::write_filter_impl::write(T&, Sink&, const typename boost::iostreams::char_type_of::type*, std::streamsize) [with T = cb::HTTP::ChunkedStreamFilter; Sink = boost::iostreams::detail::linked_streambuf >]' at src/boost/boost/iostreams/write.hpp:142:31, inlined from 'std::streamsize boost::iostreams::write(T&, Sink&, const typename boost::iostreams::char_type_of::type*, std::streamsize) [with T = boost::reference_wrapper; Sink = boost::iostreams::detail::linked_streambuf >]' at src/boost/boost/iostreams/write.hpp:55:45, inlined from 'static std::streamsize boost::iostreams::detail::flt_wrapper_impl::write(Filter&, Sink*, const typename boost::iostreams::char_type_of::type*, std::streamsize) [with Filter = boost::reference_wrapper; Sink = boost::iostreams::detail::linked_streambuf >]' at src/boost/boost/iostreams/detail/adapter/concept_adapter.hpp:278:30, inlined from 'std::streamsize boost::iostreams::detail::concept_adapter::write(const char_type*, std::streamsize, Sink*) [with Sink = boost::iostreams::detail::linked_streambuf >; T = boost::reference_wrapper]' at src/boost/boost/iostreams/detail/adapter/concept_adapter.hpp:85:32, inlined from 'void boost::iostreams::detail::indirect_streambuf::sync_impl() [with T = boost::reference_wrapper; Tr = std::char_traits; Alloc = std::allocator; Mode = boost::iostreams::bidirectional]' at src/boost/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:392:18: /usr/include/bits/string_fortified.h:34:33: error: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading 31 bytes from a region of size 16 [-Werror=stringop-overflow=] return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); ~~~^~~ In function 'void* memcpy(void*, const void*, size_t)', inlined from 'std::streamsize cb::HTTP::ChunkedStreamFilter::write(Sink&, const char*, std::streamsize) [with Sink = boost::iostreams::detail::linked_streambuf >]' at src/cbang/http/ChunkedStreamFilter.h:131:19, inlined from 'static std::streamsize boost::iostreams::detail::write_filter_impl::write(T&, Sink&, const typename boost::iostreams::char_type_of::type*, std::streamsize) [with T = cb::HTTP::ChunkedStreamFilter; Sink = boost::iostreams::detail::linked_streambuf >]' at src/boost/boost/iostreams/write.hpp:142:31, inlined from 'std::streamsize boost::iostreams::write(T&, Sink&, const typename boost::iostreams::char_type_of::type*, std::streamsize) [with T = boost::reference_wrapper; Sink = boost::iostreams::detail::linked_streambuf >]' at src/boost/boost/iostreams/write.hpp:55:45, inlined from 'static std::streamsize boost::iostreams::detail::flt_wrapper_impl::write(Filter&, Sink*, const typename boost::iostreams::char_type_of::type*, std::streamsize) [with Filter = boost::reference_wrap
Re: Mass Rebuild for Fedora 28
Strange error with camotics: Error: Problem: package cairo-devel-1.15.10-2.fc28.x86_64 requires pkgconfig(gobject-2.0), but none of the providers can be installed - conflicting requests - nothing provides /usr/bin//usr/bin/python3 needed by glib2-devel-2.55.2-1.fc28.x86_64 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Upstream installs AppData file in /usr/share/appdata
> Submit a PR upstream to fix it, and use that patch to change it locally. So I did, upstream accepted it, but then it applied old location again. As it is noted in patch description for compatibility reasons. Now application installs on both locations. Should I remove now this files from the old location or they can stay? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Upstream installs AppData file in /usr/share/appdata
Hi, I have a package where upstream installs AppData file in /usr/share/appdata, but the Fedora Packaging Guidelines says it should be installed to /usr/share/metainfo. I am wondering how to approach this; should I submit a PR upstream, should I change it locally or should I leave it unchanged. Are there any compatibility reasons to keep /usr/share/appdata upstream? https://fedoraproject.org/w/index.php?title=Packaging%3AAppData&type=revision&diff=501456&oldid=486600 https://pagure.io/packaging-committee/issue/704 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EPEL support in "master" branch (aka speeding up Fedora development)
> Oh it definitely does. > > I am handling mass rebuilds of Ruby packages or updates of Ruby on > Rails. This is complex task requiring touching plenty of packages. Due > to update of Rails in master, I simply cannot contact maintainers of all > packages and assuring their branches still works. I cannot test the > .spec files on Rawhide and EPEL just because there is chance somebody is > going to build the packages on EPEL. At the and, you cannot even trust > the EPEL macros in Fedora. > > And of course every branch specific branches makes this mass changes > more complicated, because you simply cannot script it. > > If there were no branch macros and we could consider just Rawhide doing > such changes, the .spec files in Fedora would be generally i better shape. > > > > > Vít Maybe a decent compromise would be to make maintainers of such packages responsible to fix any incompatibilities introduced by such changes. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EPEL support in "master" branch (aka speeding up Fedora development)
> Just FTR: above we have "I think" vs "in practice, it looks not like you > may think". > Real engineering is about 1) testing, 2) testing, 3) testing. > "Assumption" like, "I think" is/should be the real enemy of each > engineer. > > Stricter use of branching will have yet another effects that for example > older Fedoras will have less updates. > IMO those updates should be only about security and critical updates. > > On first look, it may look as the negative side effect because some end > users/consumers may expect some number of "refreshes" for every Fedora > release which is still not EOSed like it is now. > However, as Fedora has short development cycle not releasing those > "refreshes" for older Fedoras have IMO much greater positive effects: > > 1) easier to test upgrades between Fedora versions > > As each Fedora major release may have in updates only security and critical > fixes and ABI (libraries SONAME changes) will be completely locked down it > will be easier work on a set of test units testing upgrades on top of > different sets of installed packages. Doesn't relate to packages which rarely see an update if at all. > 2) more people (packagers and regular end users) will be focused on testing > of latest Fedora version Do you have some results of a testing or you just assume this would be the case? > Simple more eyeballs using exact latest Fedora than more likely that after > hitting sometimes small issue it will be reported to BTS. > As consequence RH people making own snapshot to start working next major EL > version may expect that they will have fewer issues to resolve after making > such snapshot. > > 3) fewer packagers will be spending time on backporting some changes Doesn't relate to packages which rarely see an update. > This is as well important because as result those people will have MORE > time to work on changes on master. In other words, it will allow better > concentration of limited man/hours resources to make each major Fedora > release better/more tested. > > > There is always cost some changes. There is no "something for nothing". > IMO in altering general policy about release updates of older Fedora > version will have the weight of those "good consequences" greater than the > weight of those "bad effects" which in some people opinion such change may > introduce. > Simple it is not possible to make happy everyone and the decisive point > should be not close to single end-user needs but in point where it is > possible to have broader/whole view of distribution issues. > At the moment as master branch is used to make every not EOSed Fedora, it > forces to use much more complicated by %ifings form of most of the Fedora > spec files, > This as consequences make many large-scale distribution changes *much more > complicated*. > > kloczek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EPEL support in "master" branch (aka speeding up Fedora development)
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Mon, 2018-01-22 at 12:31 +0100, Miroslav Suchý wrote: > > Better to introduce bugs? > > mock-core-config now requires yum on Fedora because you made wrong if in > spec... > > https://bugzilla.redhat.com/show_bug.cgi?id=1537193 > - -- > - -Igor Gnatenko I think conditionals should be documented with more examples as well [1], in order to minimize such bugs. [1] https://fedoraproject.org/wiki/Packaging:DistTag#Conditionals ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EPEL support in "master" branch (aka speeding up Fedora development)
> Dne 22.1.2018 v 12:31 Miroslav Suchý napsal(a): > > You took pretty basic example without context. So let me give you > different example. > > There were attempts to get Ruby on Rails into EPEL. It is around 80 > packages. Some packages were RHEL contidiontalized. But the effort to > get Ruby on Rails was never successful. Even if it was successful, > nobody maintained/updated it later, for example because more recent Ruby > on Rails, developers decided to drop support for older Ruby which are in > RHEL. That left some Fedora packages with some RHEL conditions and makes > every update of such package pain. These conditionals won't be ever used > again. > > Also, from my experience maintaining Ruby in RHEL and RHSCL, in 90 % > percent of cases cherry-pick of the specific fix I want to get from > Fedora works without conflicts and if there are conflicts, they are just > in changelog. > > > Vít Well I think maintainers should chose the ideal solution for their case. If use of macros just complicates things too much, maybe use of branches might make more sense. On the other hand does it really make sense to enforce maintaining different branches for a few conditionals? Also the issue is not just in maintaining branches. As it stands right now, one can grab almost any spec file from a src.rpm and have it work properly everywhere. Having said that, some specs does indeed look like a mess at a first glance, but if maintainer chose this way as a best solution for his case, I respect that. To prevent such cases become popular, I think this should be documented on guidelines so that new maintainers can make their choice appropriately and not just copy what others did. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache
If I am not mistaken, EPEL still needs quite large chunk of such scriptlets[1]. What would be the best way to maintain a SPEC file for both. https://fedoraproject.org/wiki/EPEL:Packaging#Scriptlets ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Cockpit depends on NetworkManager.
> This is clean_requirements_on_remove being helpful as usual. Never should > have been a default setting as I've argued before, and the first thing I > disable in /etc/dnf/dnf.conf. > http://dnf.readthedocs.io/en/latest/conf_ref.html#clean-requirements-on-r... > -Dan If users survived half the system being removed and rendered useless because of PackageKit bugs, I think they will survive one NetworkManager removal. What I am trying to say, that should have been done earlier, now is too late. IMHO. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Cockpit depends on NetworkManager.
Hi, You should always check the list before confirming the action. As Mathew said, it is probably an issue with package not being marked as user installed for some reason. There was an issue in the past with using PackageKit and dnf together, see: https://fedoraproject.org/wiki/Common_F24_bugs#DNF_might_remove_essential_system_packages_if_you_used_PackageKit_.28GNOME_Software.2C_KDE_Apper.29_in_the_past Such package might have been still marked wrongly, thus this issue. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package add request
Here it is: https://copr.fedorainfracloud.org/coprs/srakitnican/default/build/607839/ Still not sure about naming issue, package wants to name files ZeGrapher, I called the package zegrapher, debian maintainers go a step further and call package files zegrapher also. TODO: AppStream metadata It would be nice if build system would support install ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Call for testing - Firefox CSD/titlebar
"Edge" of the window is way off the visible one with an offset somewhere to what window is shown in the picture bellow. Resize cursor is visible way off the visible window border. https://i.imgur.com/v36YoDU.png Not sure if that is by design, minimize, maximize or close buttons don't show up unless they've been hovered over. Maybe background image has to do something with that. It would be nice if double clicking on empty space in tab bar would maximize/minimize the entire window. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Testing graphical applications inside mock fails
> Thank you for your detailed answer! > > > The error messages about drm device are gone if I manually create the > character file > inside the chroot. However the original issue remains the same. Tried a GTK > application > easystroke however and that seems to work fine even without a drm device, so > maybe it has > to do something with Qt. The Qt application camotics gives a bunch of these > messages. > > X Error: BadAccess (attempt to access private resource denied) 10 > Extension:130 (MIT-SHM) > Minor opcode: 1 (X_ShmAttach) > Resource id: 0x131 > X Error: BadShmSeg (invalid shared segment parameter) 128 > Extension:130 (MIT-SHM) > Minor opcode: 5 (X_ShmCreatePixmap) > Resource id: 0x280005f > X Error: BadDrawable (invalid Pixmap or Window parameter) 9 > Major opcode: 62 (X_CopyArea) > Resource id: 0x2800060 > X Error: BadDrawable (invalid Pixmap or Window parameter) 9 > Major opcode: 62 (X_CopyArea) > Resource id: 0x2800060 > X Error: BadDrawable (invalid Pixmap or Window parameter) 9 > Major opcode: 62 (X_CopyArea) > Resource id: 0x2800060 > ... QT_X11_NO_MITSHM=1 helps with these, though. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Testing graphical applications inside mock fails
Thank you for your detailed answer! > Short answer: > > # mknod /dev/dri/card0 c 226 0 The error messages about drm device are gone if I manually create the character file inside the chroot. However the original issue remains the same. Tried a GTK application easystroke however and that seems to work fine even without a drm device, so maybe it has to do something with Qt. The Qt application camotics gives a bunch of these messages. X Error: BadAccess (attempt to access private resource denied) 10 Extension:130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach) Resource id: 0x131 X Error: BadShmSeg (invalid shared segment parameter) 128 Extension:130 (MIT-SHM) Minor opcode: 5 (X_ShmCreatePixmap) Resource id: 0x280005f X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x2800060 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x2800060 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x2800060 ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Testing graphical applications inside mock fails
Hi, I am trying to test graphical application inside mock chroot environment as documented on Fedora wiki [1], but I am unable to do that successfully. In addition to that instructions I've installed mesa-dri-drivers and mesa-libGL inside the chroot as there were messages about missing files. But still no luck, some applications appear with an incomplete window, other ones without any. All applications that i have tested have a common error messages: libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i965 Is it possible to do that? [1] https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#Testing_graphical_applications_inside_mock ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
I agree, 15MB is too much for a server instance, especially for a container. I think AppStream data as is is more appropriate for desktop. No sure if possible, but maybe an option; don't make it a hard dependency. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Need assistance to build knotter for Fedora
There are various error messages about missing files. The project uses git submodules, make sure you provide them as well. https://github.com/mbasaglia/Knotter/tree/master/src/widgets ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: git push fails for new packages
> for f27: This is a known problem see: > https://pagure.io/fedora-infrastructure/issue/6236 > They working on it right now. > > f26 works for me now with: > $ git checkout -b f26; git push --set-upstream origin f26; fedpkg build > --nowait Used your workaround, I can't build the package now in koji with a message: BuildError: package hd-idle not in list for tag f26-updates-candidate Same with other branches other then master. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: git push fails for new packages
In addition to new package not building because of tag, by following the https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import.2C_commit.2C_and_build_your_package On step: fedpkg switch-branch BRANCH Gives: $ fedpkg switch-branch f26 /usr/lib/python2.7/site-packages/fedora/client/bodhi.py:48: DeprecationWarning: fedora.client.bodhi has been deprecated. Please use bodhi.client.bindings instead. DeprecationWarning) Could not execute switch_branch: Unknown remote branch origin/f26 Despise that branch have been approved, other branches seems that had been deleted somehow in the process. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pagure over dist-git: what changes?
Hi, How can one request new package for multiple repoes at once like it was possible with pkgdb, is this possible with this new tool? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: cbang build error on epel
> I guess it depends if (and how) inttypes.h header gets included, it's > provided by glibc. > > > Dan Find out some more information, do in both Fedora and EPEL __STDC_FORMAT_MACROS is not defined. The difference is in following patch: https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/generic/inttypes.h;h=95d781815b6023f49305a1539d03672d13525542;hp=dc97519056b885a315e970be946177c5cee0d491;hb=1ef74943ce2f114c78b215af57c2ccc72ccdb0b7;hpb=ae9552cf7b7f43591a1dfd54baf48d31fbbe9fac ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: cbang build error on epel
> GCC > 6 That should say GCC 6 and newer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: cbang build error on epel
> Argument 4 is the "n". The problem is with the definition of "PRIo64. > There was a recent commit attempting to fix that, but it probably needs > some adjustment to handle your case. Check out the lines around line 48 > in that file and see if you can patch it to work in all cases. The odd > thing is that it only doesn't work on epel7. I guess you need to > compare how old the compiler is on there compared to the Fedora versions. So Joseph and I managed to fix this for epel7 with following patch: src/cbang/tar/TarHeader.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/cbang/tar/TarHeader.cpp b/src/cbang/tar/TarHeader.cpp index 470b37c..50df710 100644 --- a/src/cbang/tar/TarHeader.cpp +++ b/src/cbang/tar/TarHeader.cpp @@ -45,7 +45,8 @@ #endif #ifndef PRIo64 -#if defined(_M_X64) || (defined(__x86_64__) && !defined(__ILP32__)) +#if defined(_M_X64) || (defined(__x86_64__) && !defined(__ILP32__)) || \ + defined(__aarch64__) || defined(__ppc64__) || defined(__PPC64__) #define PRIo64 "lo" #else #define PRIo64 "llo" It seems GCC 4.8 needs these macros defined explicitly, while GCC > 6 inherits it from something else (_M_X64 perhaps?), thoughts? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Strange situation with Wine on Fedora 27
> Hello, I'm just trying to install the Wine via dnf and get: > # dnf install wine ... Error: Transaction check error: > file /usr/share/doc/gstreamer1/NEWS from install of > gstreamer1-1.12.1-1.fc27.i686 > conflicts with file from package gstreamer1-1.12.0-1.fc27.x86_64 > file /usr/share/doc/gstreamer1/RELEASE from install of > gstreamer1-1.12.1-1.fc27.i686 Maybe, but not with the packages. What most likely happened is that package manager died in the middle of an upgrade causing old packages left behind thus causing dupes. You would need to resolve this before you can continue to use package manager for upgrades. You can check for dupes with dnf repoquery --dupes To fix it, you can use following command, dnf remove $(dnf repoquery -q --duplicated --latest-limit=-1) but first make sure you are removing about the same amount of packages as it's listed with command: dnf repoquery --duplicated --latest-limit=-1 -q | wc -l I had some issues that that command would remove most packages from the system, leaving it in unworkable state. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Coming soon: Pagure service for dist-git
IMHO, based on first impressions, new features aside. I don't like the interface responsiveness. If I compare it with cgit, cgit is reasonably fast with an nice overview. Browsing pages with packages with pagure is slower, browsing users pages is unusable, it literally takes minutes to load a page for me. Yeah, it maybe can be fixed with cache but that leads to another sets of problems like making sure page always serves fresh and accurate content. Makes me wonder, why newer software needs to be so slow... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: cbang build error on epel
> Argument 4 is the "n". Right, if I adapt the fix for 4th argument, that works. > The problem is with the definition of "PRIo64. There was a recent commit > attempting to fix that, but it probably needs some adjustment to handle your > case. Check out the lines around line 48 in that file and see if you can > patch it to work in all cases. The odd thing is that it only doesn't work on > epel7. I guess you need to compare how old the compiler is on there compared > to the Fedora versions. Not sure how to fix this myself, I've notified program author and he thinks that the code should work [1]. So I've emailed ppc list [2]. [1] https://github.com/CauldronDevelopmentLLC/cbang/issues/21#issuecomment-313770740 [2] https://lists.fedoraproject.org/archives/list/p...@lists.fedoraproject.org/thread/2UZNKRTKKAW4NOZ6SHEGXGSOWWAS2ZOX/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: cbang build error on epel
> Patch that line to read `sprintf(buf, "%0*" PRIo64, static_cast unsigned int>(length - 1), n);` and you're cool. It might be related to how
> that particular gcc version in EPEL7 inherits those atomic data-types.
I've tried with that and this is what I get.
src/cbang/tar/TarHeader.cpp:226:80: error: field width specifier '*' expects
argument of type 'int', but argument 3 has type 'long long unsigned int'
[-Werror=format=]
sprintf(buf, "%0*" PRIo64, static_cast(length - 1),
n);
^
src/cbang/tar/TarHeader.cpp:226:80: error: format '%llo' expects argument of
type 'long long unsigned int', but argument 4 has type 'uint64_t {aka long
unsigned int}' [-Werror=format=]
I've also sent a mail to ppc lists seems there is an issue somewhere in that
platform.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
cbang build error on epel
Hi,
I am building CAMotics with cbang builds successfully for i686 and x86_64
platforms, I am trying to make it work for other architectures, in particular
armv7 and ppc64 (there is no v8-314 available for others).
So while testing fixes on copr I've stumbled upon an issue of what I am not
sure about, the build for ppc64le pass for f24-f27 but fails on epel7.
src/cbang/tar/TarHeader.cpp:226:43: error: format '%llo' expects argument of
type 'long long unsigned int', but argument 4 has type 'uint64_t {aka long
unsigned int}' [-Werror=format=]
sprintf(buf, "%0*" PRIo64, length - 1, n);
^
copr test:
https://copr.fedorainfracloud.org/coprs/srakitnican/ppc64le-tests/build/576355/
cbang: https://github.com/CauldronDevelopmentLLC/cbang/
Is this really an issue in cbang?
Best regards,
Samuel Raktiničan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Rotation logs - use or not to use
> Cheers all, > > I'm trying to do something with a patch in MariaDB, but I need to know > current situation about rotation logs. > > *What's the problem:* > Upstream ship rotation log, we drop it out. > This started sometimes between F15 and F16. Mostly because (for what I > read) Fedora didn't like rotation logs, there were issues in them, they > were often broken and so on. I though logrotate is mandatory? https://fedoraproject.org/wiki/Packaging:Guidelines#Log_Files ___ 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
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: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide
> Hi, > > A while back Debian has switched to using the modesetting Xorg driver > rather then the intel Xorg driver for Intel GPUs. > Hello, Is it possible to configure xserver to use "intel" driver without recompiling it? Best regards, Samuel > Regards, > > Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: sudo not looking into /usr/local
> Am 16.11.2016 08:08, schrieb Samuel Rakitničan: > > You can change the default behaviour in "/etc/sudoers" or (better) by > adding a file in "/etc/sudoers.d". > > If you want to keep the users path, add: > > Defaults env_keep += "PATH" > Defaults !secure_path > > or to change the (default) secure path, just add > > Defaults secure_path = /your/path/here:/as/usual File in /etc/sudoers.d is neat, thanks. But I am hoping we can came up with a new default setting or is there a reason not to include anything else? I was thinking about it some more, and I think this setting does more harm then good. It limits what users can do but it doesn't stop them to bypass it with a simple alias sudo="sudo PATH=$PATH". So in my opinion the original "If you don't trust the people running sudo to have a sane PATH environment variable you may want to use this." kind of defeats its purpose. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: sudo not looking into /usr/local
> On Tue, 2016-11-15 at 18:42 +0000, Samuel Rakitničan wrote: > > What about -E option? Thanks for that, didn't take this into consideration. -E option however seems to have no effect on PATH environment variable. $ sudo -E env | grep ^PATH PATH=/sbin:/bin:/usr/sbin:/usr/bin Following however works, but I don't find it convenient, I might as well type in the whole path (easier to remember). More so, I don't want the whole user's PATH including user's /home, but just fewer safe locations. $ sudo PATH=$PATH env | grep ^PATH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
sudo not looking into /usr/local
Hi, Something I stumbled upon today is that there is no convenient way by default to make some custom script accessible via sudo without specifying full path. Found out that sudo have limited set of paths in its environment that is looking into [1]. Sadly, none of it is appropriate for custom scripts. I think it would be nice to include /usr/local/bin and /usr/local/sbin also. [1] http://unix.stackexchange.com/a/8652 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
> Since I like to use terminal a lot, I would prefer if you keep it short! > > If you must include branding I would prefer shorter version of "Fed" or > "fed" so ideally something like "fed12345". Shorter hostname is not only useful when typing commands, but anywhere else where it is used. For example journalctl logs. You don't want hostname to take half of the screen? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
Since I like to use terminal a lot, I would prefer if you keep it short! If you must include branding I would prefer shorter version of "Fed" or "fed" so ideally something like "fed12345". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: DNF and PackageKit background data usage
> On Sat, 2016-11-05 at 05:01 +0100, Kevin Kofler wrote: > > "hunt down"? > > koji download-build (nvr) works fine. I think you are missing the point here. Reverting dnf history does not work if packages are missing from repository. Besides "koji" command is not installed on my machine, and hence not on default install. Your suggestion for users is to install "RPM Development Tools" group? I don't see how this command would help in what I usually do when I need stuff that is missing from repo, other then a little bit more convenience perhaps. That is to locate the packages in koji.fedoraproject.org and pass the urls to curl. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Blivet-GUI in Anaconda
> = Proposed Self Contained Change:Blivet-GUI in Anaconda = > https://fedoraproject.org/wiki/Changes/AnacondaBlivetGUI > > Change owner(s): > * Martin Kolman * Vojtěch Trefný > > Add blivet-gui as an alternative option for storage configuration in > Anaconda Installer. > > > == Detailed Description == > Add blivet-gui as an alternative option for storage configuration in > Anaconda Installer. > Unlike the current custom partitioning screen in Anaconda, which works > in a top-down way (user specifies mountpoints and their properties), > blivet-gui works with the bottom-up principle (user has full control > to assemble the storage configuration from individual members). By > integrating blivet-gui into anaconda we will make the bottom-up > partitioning available to users during the installation. Blivet-gui is > built on top of the blivet library, which is used by Anaconda for > storage configuration, this makes the change very easy to implement > and doesn't bring new code and dependecies into the installer other > than a relatively small GUI package. > > > == Scope == > * Proposal owners: > - blivet-gui devs: Prepare blivet-gui for integration into Anaconda -- > change the UI to look consistently while running fullscreen inside an > Anaconda spoke, change look and feel of blivet-gui dialogs to match > Anaconda dialogs, add storage configuration sanity checking into > blivet-gui. > - anaconda devs: Add an option to use blivet-gui to the Storage spoke, > add blivet-gui package as a dependency of the anaconda package so that > it is pulled into the installation environment and also add an option > to not show blivet-gui in anaconda if requested (see > https://github.com/rhinstaller/anaconda/blob/master/docs/user-interaction... > for detailed explanation how hiding spokes works in Anaconda). > > * Other developers: N/A (not a System Wide Change) > > * Release engineering: N/A (not a System Wide Change) > > * List of deliverables: N/A (not a System Wide Change) > > * Policies and guidelines: N/A (not a System Wide Change) > > * Trademark approval: N/A (not needed for this Change) Will this allow to manually partition partially partitioned disk? I never managed to do that with anaconda and had to use gparted from Live media. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: duplicate package on fresh install
> On Fri, Sep 23, 2016 at 5:34 AM, Nikos Mavrogiannopoulos > > Could be lots of reasons. An x86_64 and i686 library installed > simultaneously can appear confusingly as duplicate libraries if you > don't ask rpm to report architecture. A system interruption during the > update can block rpm from clearing the old entries in its database. Or > a failure of '%post' operations can cause the update to fail partway > through. > > The usual answer if there are genuinely two copies reported is to do a > "reinstall" if it's two distinct versions of the same package, and to > do an "rpm --rebuilddb" and see if that helps. Reinstall or any other dnf operation except remove doesn't work, didn't try --rebuilddb. There are many cases of such broken state on forums, but system is usually working fine AFAICT. Is there a way to alter rpm database to remove one version of a package without altering the system? > > > > regards, > > Nikos > > > > [0]. https://bugzilla.redhat.com/show_bug.cgi?id=1378781 > > ___ > > devel mailing list -- devel(a)lists.fedoraproject.org > > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intelligentmirror needs a refresh
Since then I have found out that intelligentmirror-0.5-1 is not ideal. It works but if package is not cached download happens twice (One at the mirror, one at the client) making it not very efficient. That and since it is fairly difficult to set up considering all the problems with obsolete configuration, I have found out that far more better option is to use Squid's 3.4 and newer Store ID feature. This way only a small script is required that "maps" packages to cache [1]. I recommend a wiki [2] update accordingly. [1] https://github.com/yevmel/squid-rpm-cache [2] https://fedoraproject.org/wiki/Infrastructure/Mirroring#How_can_someone_make_a_private_mirror.3F -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Intelligentmirror needs a refresh
intelligentmirror-0.5-1.noarch.rpm installs with a couple of issues: 1. It's missing apache configuration line with "Require all granted" 2. SELinux is blocking it by default so I suppose it needs a policy file? I know that intelligentmirror is not in fedora repositories and thus not officially supported, but it is a shame that doesn't work out of the box because in my opinion is a very useful piece of software. If anyone would care to take a look at it that would be awesome. https://kulbirsaini.fedorapeople.org/stuff/intelligentmirror/ https://github.com/kulbirsaini/intelligentmirror -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Firefox on Wayland
> On 06/28/2016 12:13 PM, Martin Stransky wrote: > > New fixed package is available at Copr. > ma. Fixed the launcher crash for me. Window repainting [1] is still an issue for me, though, which makes it kind of unusable under wayland. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1349016 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Firefox on Wayland
> I've failed to launch the application properly under X.org and Wayland using > the > launcher icon in GNOME shell. > > But when I switched to Wayland, I executed the `firefox` command from > "Terminix" > and it worked under XWayland with no regressions so far (I didn't notice any > other > than links from other apps can't be opened as it tries to open new instance of > Firefox). Having this issue as well. It crashes under wayland when launched from .desktop file for some reason, but not if started directly with "firefox" from gnome-terminal. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
