OpenSSL security fix
A new incoming OpenSSL security fix for high rated security bug https://mta.openssl.org/pipermail/openssl-announce/2015-July/37.html -- 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: OpenSSL security fix
new update http://openssl.org/news/secadv_20150709.txt -- 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: Bad default error policy causes printing issues and BIG usability issues
Il 06/12/2014 19:29, valent.turko...@gmail.com ha scritto: > Who is responsible for user experience of Fedora desktop? To whom > should I point this issue to? https://fedoraproject.org/wiki/QA you could also fill a bugreport against CUPS component in https://bugzilla.redhat.com/ I agree with you. I migrated some offices to Fedora and sometimes I receive phone calls about printing troubles. When I go personally to check what is wrong I often saw a big CUPS queue and the printer in pause -- 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: Looking for new maintainer: ownCloud (Fedora / EPEL)
Il 31/08/2015 18:19, Adam Williamson ha scritto: > There isn't really a great alternative to ownCloud (that I know of) if > you actually *want* a 'personal cloud server' with all the bits OC > has, but I realized I just don't and I can't stand the pain of > maintaining that beast just to keep my calendar and contacts > synchronized. I do honestly feel bad about it, but I'd rather be up- > front than pretend I'm still doing it but actually never get around to > it. What about OpenAtrium? http://openatrium.com -- 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: Proposal to reduce anti-bundling requirements
I have read the whole discussion and I would like to share my opinion, even if I think it could be a bit off-topic. Given that Fedora community alone, cannot educate every upstream developer about unbundling, and considering that it is a problem that interests all main Linux distributions: I think that Fedora community could (and should) propose to other Linux distribution communities to make a general effort to kindly ask upstream devs to reconsider their work, enforcing unbundling. This will take years, but I think it is a way we should cover. -- 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: DNF: no helpful information in case of dependency problems
it's similar to "dnf does not report which packages cause conflicts" https://bugzilla.redhat.com/show_bug.cgi?id=1261887 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Disable PulseAudio flat volumes to prevent it from pushing volume level to max
=== Definition of flat-volumes from [1] : it scales the device-volume with the volume of the "loudest" application. For example, raising the VoIP call volume will raise the hardware volume and adjust the music-player volume so it stays where it was, without having to lower the volume of the music-player manually. === Today I had a scary experience with the audio of my computer. I was listening to music with Amarok, using my headphones... The KMix volume level was ~ 35%. When I logged into a video conference application, the volume suddenly reached the 100%. I was shocked, having the maximum audio level shooted in your ears is a painful experience. The conference application that triggered PulseAudio pushing volume to maximum level probably should have never asked the system for a 100% audio level, but on the other hand, PulseAudio should never allow an application to make such sudden changes. To avoid that, you have to set flat-volumes = no in /etc/pulse/daemon.conf I found many users stories complaining about this default setting [2] [3] [4] and you can easily find other by searching "pulseaudio flat volumes". I completely agree with user gaggra comment at [3] <> Moreover this default setting can cause sound crackling [5]. So I would like to start a discussion about disabling this default behaviour for the mentioned reasons. [1] https://wiki.archlinux.org/index.php/PulseAudio [2] https://major.io/2015/06/08/pulseaudio-popping-with-multiple-sounds-in-fedora-22/ [3] https://www.reddit.com/r/linux/comments/2rjiaa/horrible_decisions_flat_volumes_in_pulseaudio_a/ [4] http://awesomelinux.blogspot.it/2013/06/pulseaudios-dynamic-volume-levels-are.html [5] https://bugzilla.redhat.com/show_bug.cgi?id=1264177 -- 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: Disable PulseAudio flat volumes to prevent it from pushing volume level to max
Il 17/09/2015 21:13, Andrew Lutomirski ha scritto: > > To clarify: did you get blasted by music or by video conference > sounds? If the music volume got louder, then it sounds like either a > straight-up bug in PulseAudio (and a severe and dangerous one at that) > or a serious bug in your video conference volume in which it adjusts > the volume of streams other than its own. > > If you got blasted by video conference sounds, then I'd say it's a > serious design flaw in PulseAudio. PulseAudio should offer an > easy-to-configure maximum volume (probably A-weighted power, but peak > level works, too, if considerably less well) on a per-output basis > with which to protect your ears. > > --Andy I got blasted from the music because I was not making a conference, I only logged into the software, so the music was the only sound I was listening to. PulseAudio pushed the master audio level to 100% (therefore all applications audio level changed to 100%, due flat-volume setting). -- 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: Trying to contact package maintainer for boinc-client
The actual BOINC working mantainer is Mattia Verga -- 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: Disable PulseAudio flat volumes to prevent it from pushing volume level to max
Il 21/09/2015 21:45, Thomas Daede ha scritto: > Is there currently a bug open for this? I'd rather it not get lost. I think that a FESCo ticket would be more appropriate. I will open it during next days. -- 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: Disable PulseAudio flat volumes to prevent it from pushing volume level to max
Il 22/09/2015 03:43, Rex Dieter ha scritto: > Germano Massullo wrote: > >> Il 21/09/2015 21:45, Thomas Daede ha scritto: >>> Is there currently a bug open for this? I'd rather it not get lost. >> I think that a FESCo ticket would be more appropriate. > I think it would be premature to appeal to FESCo without giving pulseaudio > maintainers a chance to respond to your proposal first. > > Mind filing a bug with your proposal ? > > -- Rex > Here we go https://bugzilla.redhat.com/show_bug.cgi?id=1265267 -- 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: Trying to contact package maintainer for boinc-client
Lastest update [1] has been submitted by user [2] that is a provenpackager **What is a provenpackager?** Provenpackagers are members of the 'provenpackager' group. In addition to the rights granted to members of 'packager', provenpackagers are able to commit changes to packages they do not own or maintain. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2015-12667 [2] https://bodhi.fedoraproject.org/users/corsepiu -- 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: dnf is completly broken
You may want to give a look to https://github.com/rpm-software-management/dnf/wiki/Hacking#logging -- 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: Trying to contact package maintainer for boinc-client
Hi Laurence, did you receive admin rights from the package mantainer? https://admin.fedoraproject.org/pkgdb/package/boinc-client/ I just made the same request because I would like to help -- 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: dnf is completly broken
In past days I experienced the following problem "dnf install" exits if there is a non existing package in the requested packages list" https://bugzilla.redhat.com/show_bug.cgi?id=1268606 -- 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: dnf is completly broken
Il 04/10/2015 16:32, Neal Gompa ha scritto: > On Sun, Oct 4, 2015 at 10:24 AM, Germano Massullo > mailto:germano.massu...@gmail.com>>wrote: > > In past days I experienced the following problem > "dnf install" exits if there is a non existing package in the > requested > packages list" > https://bugzilla.redhat.com/show_bug.cgi?id=1268606 > > > Do you have " > strict=True > " in > /etc/dnf/dnf.conf > ? > No -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DNF and regular expressions
What is wrong with DNF's regular expression # dnf remove *debuginfo*.fc20.x86_64 ? I am on F22 but I have a lot packets that should match that regular expression, but dnf does not find them. I also tried to add some escape chars like dnf remove *\-debuginfo\-*.fc20.x86_64 but the result is the same -- 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: DNF and regular expressions
Il 29/06/2015 12:18, Ondrej Oprala ha scritto: > I think dnf only supports globbing in this case ... try dnf remove > '*debuginfo*' to protect the *-s from being expanded by the shell # dnf remove '*debuginfo*' will remove all packages, I need only to remove fc20 debuginfo packages. # dnf remove '*debuginfo*'.fc20.x86_64 does find anything to remove. -- 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: DNF and regular expressions
Il 29/06/2015 12:25, Reindl Harald ha scritto: > > dnf remove '*debuginfo*.fc20.x86_64' > anyways, it's a terrible regression compared to yum Same result -- 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: DNF and regular expressions
Il 29/06/2015 16:28, Jan Zelený ha scritto: > However, there is a bug[2] open for this. If you provide your use case > there, it will help prioritizing the bug. [2] > https://bugzilla.redhat.com/show_bug.cgi?id=1199432 Thank you, I will provide my use case -- 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: DNF and regular expressions
Il 29/06/2015 17:05, David Howells ha scritto: > Germano Massullo wrote: > >> What is wrong with DNF's regular expression >> # dnf remove *debuginfo*.fc20.x86_64 > Do you mean 'regular expression' or did you mean 'glob'? > > If you did mean 'regular expression', then did you want: > > dnf remove .*debuginfo.*[.]fc20[.]x86_64 > > David I meant glob, sorry -- 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: DNF and regular expressions
Il 29/06/2015 20:32, Reindl Harald ha scritto: > > that may be true but you hardly can sell DNF as improvement if you > need such workarounds while YUM worked perfectly for many years while > working around the package manager in general should be avoided > because no longs, no dependency solving and no useful confirmation > > given that the dnf autocompletion is also horrible slow comapared with > YUM i see still no advantages from the change, try "yum cl" > versus "dnf cl", in case of DNF it feels like a network request Then I think we should open some tickets/enhancement requests -- 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: FESCO Elections - June 2015 - Results
Il 30/06/2015 10:13, Richard W.M. Jones ha scritto: > Didn't even know it was happening. Where was it announced? Rich. On devel-annou...@lists.fedoraproject.org and annou...@lists.fedoraproject.org -- 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: Self Introduction: Stefano Figura (returntrip)
Hi Stefano, welcome among Fedora contributors! ___ 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
fedbot spamming in #fedora
Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times per day about Fedora respins update? [16:51] *** F32-20200715 updated lives available: https://tinyurl.com/Live-respins2 Built by the Fedora Respin Sig more info #fedora-respins *** ___ 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
Remove all non UK/USA English spell checker variants from default Fedora installation
All desktop oriented Fedora installers install on the system packages: hunspell hunspell-en hunspell-en-GB hunspell-en-US When a user opens the language list of the spell checker, is has ~24 different English options, like English (Antigua and Barbuda), English (Australia), English (Bahamas), English (Belize), etc. (See screenshot [1]) People who are not native English speakers have this list even bigger because they will have their own language entry, plus others. Since the huge list is brought by hunspell-en, can we just ship Fedora with hunspell-en-GB and hunspell-en-US ? Another option could be to move all non GB/USA English variants to other hunspell-en-* packages as I said in ticket [2] [1]: https://bugzilla.redhat.com/attachment.cgi?id=1701536 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1858241 ___ 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
git commits&branches mess up
I have done some mistakes in [1] 1) I edited the file once to remove 32 bit CPU support, then I have done the push to master 2) I saw that I have forgotten to add changelog, so I edited the file again, I made a new push to master 3) I started merging the F21 branch to the master and I got the conflict I have found a solution like [2], but I am afraid of making things get worse... Thank you for your time [1]: http://pkgs.fedoraproject.org/cgit/darktable.git/tree/darktable.spec [2]: http://stackoverflow.com/questions/881092/how-to-merge-a-specific-commit-in-git -- 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: git commits&branches mess up
Thank you, I was trying to solve with [1] but your > $ git checkout master -- darktable.spec # solve the conflict by taking the > file as it is in master is the key of success :-) [1]: https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Retire a package from Fedora i686 (not x86_64)
I just removed 32bit CPU support from Darktable's spec file due technical reasons. Are there any other things I need to clean up in Fedora infrastructure? -- 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: Retire a package from Fedora i686 (not x86_64)
For example, SSE3 instructions set is one of the minimum requirements and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott architecture supports it. -- 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: Retire a package from Fedora i686 (not x86_64)
Il 07/11/2015 04:29, Ralf Corsepius ha scritto: > I don't see sse3 in /proc/cpuinfo of any machine I have, but I also > don't see any runtime error/warning from darktable. Because SSE3 is shown as "pni", Prescott New Instructions [1] [2] [1]: https://en.wikipedia.org/wiki/SSE3 [2]: http://unix.stackexchange.com/questions/43539/what-do-the-flags-in-proc-cpuinfo-mean -- 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: Retire a package from Fedora i686 (not x86_64)
A few lines of IRC chat, Freenode #darktable. Hanatos is Darktable project founder. [09:17] ``requiring SSE3 is not really allowed '' [09:17] so much bundled cluelessness :/ [09:19] Germano: re 32-bit [09:19] the sse thing is one thing [09:20] the other is the very limited virtual address space (2G really) [09:20] everybody coding anything half way serious will tell you the same story [09:20] (rawtherapee has the same issues iirc) [09:20] our old cache was allocing one big chunk of memory at startup and maintained it manually [09:20] essentially duplicating a poor man's malloc, specialised for our thumbnail caches [09:21] the new cache is much faster and easier to read [09:21] but based on malloc/free [09:21] which means your virtual address space (not the physical one mapping to your ram) [09:21] will get fragmented and you quickly start addressing blocks above the 10G range [09:22] which may not be a problem, even on systems with only 2G of physical ram, because blocks have been freed in between. it's just on 32-bit systems you can't address it any more and die [09:22] basically, at this point, DT makes no sense on x86, except maybe dt-cli [09:22] which is a similar argument as the sse3 is. [09:22] it's just not a worthwhile experience running this software on this kind of hardware [09:22] boucman: yes, that. [09:23] hanatos_: I think jmalloc is also more clever than glibc malloc wrt fragmentation. that's why blender uses it, afaik [09:24] *je [09:24] Germano: so i'd like to contradict the `upstream doesn't care' bit [09:25] upstream does care. [09:25] just not about random principles and guidelines [09:25] but about how well darktable runs [09:25] Artefact2: jemalloc you mean [09:25] hanatos_: yes [09:25] yes, it's mostly multithreaded/ [09:25] block per thread [09:25] might be worthwhile when running many threads for thumbnail gen [09:25] but honestly i doubt it [09:26] it speeds up another piece of code i wrote [09:26] which uses many 10s of 1000s of malloc calls per second.. [09:26] we don't do that in dt [09:26] (or tcmalloc for that matter) [09:26] simple enough to try with an LD_PRELOAD [09:26] oh yeah. calling malloc this many times is a bad idea anyway [09:32] the alternative would have been allocate ridiculous amounts of memory up front [09:32] bad idea, too [09:32] but if you have a better solution i'd sure like to hear it :) [09:32] the problem is to construct a binary search tree [09:32] i'm not a memory guru, sadly :| [09:32] in parallel [09:32] so you start at the root and push the children as new jobs (malloc job_t) [09:32] and so on [09:33] it's millions of nodes total, so you don't want to allocate them up front [09:33] maybe a compromise. allocate a pool that can store, say 10 jobs at a time [09:34] (and yes, i would agree.. calling malloc is almost always a bad idea, unless you can't avoid it) [09:34] but see.. that pool per thread.. that's exactly what jemalloc/tcmalloc do [09:34] this way you reduce the allocator load by a factor of 10, while still not allocating huge amounts of contiguous memory [09:35] maybe the issue is elsewhere. what are you doing millions of? is it possible to make "bigger" jobs and have less of them? ie a smaller tree [09:38] nope, can't touch the tree [09:38] its some spatial acceleration structure for ray tracing [09:39] it's been optimised for fast ray tracing for many years [09:39] are we still talking about darktable? didn't know it needed a raytracer [09:40] no, different piece of code.. as i said, i don't think darktable needs thread-cached malloc [10:11] Germano: also feel free to refer those guys here to us if they have questions. seems to me that some direct contact may be better. -- 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: Retire a package from Fedora i686 (not x86_64)
A clear example of the mentioned problems for Darktable 32 bit http://redmine.darktable.org/issues/10717 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Lua 5.2
Hi, I would like to ask "lua" and "compat-lua" maintainers if it is possible to have a packaged 5.2 lua version. A use case? Upstream Darktable ships a bundled Lua version 5.2, and it is not compatible with Lua 5.3. Fedora's Darktable does not ship the bundled Lua to respect Fedora packaging rules. -- 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: Lua 5.2
2015-11-19 10:51 GMT+01:00 Hans de Goede : > Hi, > > On 18-11-15 08:06, Germano Massullo wrote: > >> Hi, I would like to ask "lua" and "compat-lua" maintainers if it is >> possible to have a packaged 5.2 lua version. >> A use case? Upstream Darktable ships a bundled Lua version 5.2, and it is >> not compatible with Lua 5.3. Fedora's Darktable does not ship the bundled >> Lua to respect Fedora packaging rules. >> > > If Darktable is using 5.2, it is likely being actively maintained > upstream. So you could ask Darktable upstream to move to 5.3 for > some future version and use a bundled 5.2 in the mean time. > > compat-lua is mostly used by some somewhat older games who > are not being updated by upstream and which cannot easily > be ported to 5.2. > > Regards, > > Hans > darktable developers said that the migration to Lua 5.3 has not yet planned, so I will keep disabled the bundled version -- 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: Fedorahosted ssh keys
Il 22/01/2016 14:50, Sam Varshavchik ha scritto: > Unable to pull from a fedorahosted git repo after updating my ssh keys. > > I uploaded my updated SSH keys to FAS, they're there. Is there a > separate place to update my ssh keys for fedorahosted git, or is there > a sync delay? As far I remember, the update is not immediate, you should wait for a certain amount of time -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F25 Self Contained Change: Release Engineering Automation Workflow Engine
Il 03 giu 2016 18:48, "Adam Williamson" > YAAAY LOL -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Testing request: AMD chipset kernel issue
I am very busy in these weeks, but if you need other testing cases, I have many AMD machines -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Giovanni Simoni
Ciao Giovanni, welcome! Thank you for all the work that you will do for the Fedora Project! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Guido Aulisi
Hi Guido, welcome! Have you already chosen a sponsor? [1] Have a nice day [1]: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Review swap
I would like to take it, but I see that is already taken. Do you want to change reviewer? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Simple python package review swap - python-feedgenerator
Taken! Could you review my https://bugzilla.redhat.com/show_bug.cgi?id=1375222 Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Abandoning boinc-client
Hi Mattia. Thank you for your work. For various reasons I am in contact with the mantainer on Debian (Gianfranco Costamagna). Weeks ago he saw the Fedora commits for BOINC and he told me that he was working on same problems too (but on Debian they have done more fixes). As soon as possible I will try if it is possible to adapt Debian's BOINC code into Fedora and do some tests. If the software will work, I could became a co mantainer and consider to work together with Gianfranco. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ovirt status and ovirt alternatives
I have noticed that the most important ovirt packages have been orphaned and/or retired, so ovirt user experience seems to be compromised. Was that on purpose? What are some good alternatives? Thank you very much ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora spins torrents statistics
As torrents seeder of certain Fedora spins, I would like to share some upload statistics: 47.81 GB Fedora 25 KDE x86_64 29.40 GB Fedora 25 KDE i386 24.14 GB Fedora 25 Xfce i386 21.96 GB Fedora 25 Xfce x86_64 20.09 GB Fedora 25 LXDE x86_64 19.45 GB Fedora 25 LXDE i386 Torrents have been added on 25 November 2016 Best regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora spins torrents statistics
Il 03/05/2017 18:38, Adam Williamson ha scritto: > Can't conclude that from a single seeder, as we're missing information > on *how many seeders there are* for each torrent. 47.81 GB Fedora 25 KDE x86_64 51 seeders 29.40 GB Fedora 25 KDE i386 19 seeders 24.14 GB Fedora 25 Xfce i386 15 seeders 21.96 GB Fedora 25 Xfce x86_64 35 seeders 20.09 GB Fedora 25 LXDE x86_64 22 seeders 19.45 GB Fedora 25 LXDE i386 23 seeders ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review swap: keepassxc - Cross-platform password manager
Hello, I am looking for a review swap: here is mine: keepassxc - Cross-platform password manager https://bugzilla.redhat.com/show_bug.cgi?id=1450633 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Review swap: keepassxc - Cross-platform password manager
Review request has been taken ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Security of confined user/application and access to video group
Hi there, I am the co-maintainer of boinc-client [1]. boinc-client runs as a service, and both it and its working units run as 'boinc' user and they are confined by SELinux. Recently, I investigated to figure out why boinc-client, while running as a service, could not detect videocard for GPU calculus. In order to fix this problem I had to add Group=video to boinc-client systemd unit file. I have not yet pushed such change to boinc-client Fedora git, because I would like to ask you if this can cause a breach into boinc-client confinement. I mean, I am wondering if a process that can have access to videocard, could for example read what you are doing on your machine, the passwords you copy and paste, etc. What do you think about? Best regards For convenience I attached boinc-client unit file = [Unit] Description=Berkeley Open Infrastructure Network Computing Client Documentation=man:boinc(1) After=network-online.target [Service] Type=forking Nice=10 User=boinc WorkingDirectory=/var/lib/boinc ExecStart=/usr/bin/boinc_client --daemon --start_delay 1 ExecStop=/usr/bin/boinccmd --quit ExecReload=/usr/bin/boinccmd --read_cc_config ExecStopPost=/bin/rm -f /var/lib/boinc/lockfile IOSchedulingClass=idle Environment=LD_LIBRARY_PATH=/opt/amdgpu-pro/lib64 Group=video [Install] WantedBy=multi-user.target = [1]: https://admin.fedoraproject.org/pkgdb/package/rpms/boinc-client/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security of confined user/application and access to video group
Ah, forget the line Environment=LD_LIBRARY_PATH=/opt/amdgpu-pro/lib64 since it is needed only for my system ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security of confined user/application and access to video group
2017-06-06 14:40 GMT+02:00 Lennart Poettering : > Note sure what "boinc-client" does, but if this isn't turstworthy then > it probably shouldn't be able to get access to "video". boinc-client is the client side version of BOINC (Berkeley Open Infrastructure for Network Computing). You can use your computers to help scientific research of many different projects. You can think about it as a music player, the projects as the music discs, and the working units as disc tracks. Since working units are closed source software we always considered them not trustworthy, therefore they always runned confined as much as possible >> ExecStopPost=/bin/rm -f /var/lib/boinc/lockfile > > If this file is not supposed to survive a daemon restart it really > should be placed in /run somewhere. > I will take care of this. >> Group=video > > I have the suspicion you should better > use SupplementaryGroups=video than Group=, [...] I will not use any of them, as soon as possible I will start investigating on using udev/ACLs on dri/render to solve the GPU detection problem. Thank you for clarifing my dubts Lennart Have a nice day! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security of confined user/application and access to video group
Il 07/06/2017 09:22, Lennart Poettering ha scritto: > On Tue, 06.06.17 17:44, Germano Massullo (germano.massu...@gmail.com) wrote: > >> 2017-06-06 14:40 GMT+02:00 Lennart Poettering : >>> Note sure what "boinc-client" does, but if this isn't turstworthy then >>> it probably shouldn't be able to get access to "video". >> boinc-client is the client side version of BOINC (Berkeley Open >> Infrastructure for Network Computing). You can use your computers to >> help scientific research of many different projects. You can think >> about it as a music player, the projects as the music discs, and the >> working units as disc tracks. >> Since working units are closed source software we always considered >> them not trustworthy, therefore they always runned confined as much as >> possible > If so, this sounds like a great candidate for using systemd's > sandboxing functionality. Things like CapabilityBoundingSet=, > PrivateTmp=, ProtectSystem=, ProtectHome=, ProtectKernelTunables=, > ProtectKernelModules=, ProtectControlGroup=, SystemCallFilter=, > SystemCallArchitectures=, RestrictAddressFamilies=, > RestrictNamespaces=, RestrictRealtime=, ... > > See systemd.exec(5) for more information. > > Lennart > Thank you, I will consider systemd sandboxing too ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[RFC] Use industry-proven solution for XML routines
Fedora has a strong history of collaboration with upstream. A guy, Artem Vorotnikov, is developing Volunode[1] a fork of boinc-client very focused on improving Linux side of such software. As boinc-client co-maintainer, I really appreciated what he doing at the moment, so I will start the packaging process for Fedora/EPEL in next future. I am writing to you because I would like that Fedora community could help him, providing feedbacks about a RFC he made about usage of XML routines [2]. If you cannot reply to Github page [2], feel free to write in this mailing list, and I will forward your replies to him. Thank you very much [1]: http://volunode.com/about/ [2]: https://github.com/volunode/volunode/issues/2 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: PkgDB search / info functionality
To search packages you could use https://apps.fedoraproject.org/packages/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Preventing broken updates tree (packages downgrade) during release upgrades
There are many package maintainers who caused F25 packages being newer than F26 packages, so during F25->F26 upgrade, dnf wanted to downgrade them, for example packages quoted below. I think that bodhi quality assurance should be improved to prevent such events that break updates "tree" expat i686 2.2.0-2.fc26 fedora 91 k expat x86_64 2.2.0-2.fc26 fedora 92 k expat-debuginfox86_64 2.2.0-2.fc26 fedora-debuginfo 199 k expat-develx86_64 2.2.0-2.fc26 fedora 62 k httpie noarch 0.9.4-7.fc26 fedora106 k mariadbx86_64 3:10.1.21-5.fc26 fedora6.4 M mariadb-common x86_64 3:10.1.21-5.fc26 fedora 68 k mariadb-config x86_64 3:10.1.21-5.fc26 fedora 31 k mariadb-debuginfo x86_64 3:10.1.21-5.fc26 fedora-debuginfo 98 M mariadb-devel x86_64 3:10.1.21-5.fc26 fedora918 k mariadb-embedded x86_64 3:10.1.21-5.fc26 fedora4.2 M mariadb-errmsg x86_64 3:10.1.21-5.fc26 fedora205 k mariadb-libs x86_64 3:10.1.21-5.fc26 fedora661 k mariadb-server x86_64 3:10.1.21-5.fc26 fedora 18 M mariadb-server-utils x86_64 3:10.1.21-5.fc26 fedora2.2 M pcre i686 8.40-7.fc26 fedora203 k pcre x86_64 8.40-7.fc26 fedora202 k pcre-cpp x86_64 8.40-7.fc26 fedora 40 k pcre-debuginfo x86_64 8.40-7.fc26 fedora-debuginfo 1.2 M pcre-devel x86_64 8.40-7.fc26 fedora546 k pcre-utf16 x86_64 8.40-7.fc26 fedora188 k pcre-utf32 x86_64 8.40-7.fc26 fedora179 k pyp2rpmnoarch 3.2.1-3.fc26 fedora 76 k qt5-qtbase x86_64 5.7.1-15.fc26 fedora3.0 M qt5-qtbase-common noarch 5.7.1-15.fc26 fedora 32 k qt5-qtbase-debuginfo x86_64 5.7.1-15.fc26
Concerning Beignet OpenCL driver stability
As darktable co-maintainer, I am getting a lot of crash reports related to Beignet OpenCL driver (see below). Recently darktable developers inserted Beignet into blacklist because they state that it is a poorly maintained OpenCL driver. Since it is a library shipped by default on Fedora installations, I would like to know if there are any positive feedbacks about Beignet usage https://bugzilla.redhat.com/show_bug.cgi?id=1195367 https://bugzilla.redhat.com/show_bug.cgi?id=1460400 https://bugzilla.redhat.com/show_bug.cgi?id=1468392 https://bugzilla.redhat.com/show_bug.cgi?id=1469023 https://bugzilla.redhat.com/show_bug.cgi?id=1470161 https://bugzilla.redhat.com/show_bug.cgi?id=1468977 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Concerning Beignet OpenCL driver stability
Looks like the problem has been fixed -> https://bugzilla.redhat.com/show_bug.cgi?id=1470876#c6 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Python packages not compliant to Fedora guidelines
In past days I filled many review requests for various python libraries, in order to submit python-netdiff [1] and python-django-netjsongraph [2]. During this process, I noticed that a lot of python packages are not compliant to Fedora Guidelines for packaging Python stuff [3]. So you have to deal with many packages that have the old naming (python-*) and are not using the new python2-* and python3-* Moreover there are packages that have newer branches that are compliant to guidelines and older that are not, so the result is that you have a *your* package that builds for example on >= F23 but does not on F22, and maybe on EPEL7 too. I think it would be nice if we put some effort to have all those problems fixed for F24 release [1]: https://pypi.python.org/pypi/netdiff [2]: https://pypi.python.org/pypi/django-netjsongraph [3]: https://fedoraproject.org/wiki/Packaging:Python -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Orphaned LemonPOS
I orphaned package LemonPOS. Upstream developer seems to not be longer working on the project, and the software is not stable and reliable as it should. Best regards -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Package presentation: python-netdiff
Hi, I would like to present you a package that has just been accepted to be in Fedora repositories: python-netdiff. Netdiff is a Python librarybased on networkxthat provides utilities for parsing network topology formatsof open source dynamic routing protocols (like OLSR [2], BATMAN [3]) and detecting changes in these topologies. It provides standard NetJSONNetworkGraph[4] output facilitating the detection of changes in network topology (more infos at [1]). Main contributors come from European wireless communities like Ninux.org [5] [6] and Gufi.net [7] Some examples of netdiff use are software projects nodeshot [8] and django-netjsongraph [9] The package should be available in stable repo in a few days. Have a nice day [1]: https://github.com/ninuxorg/netdiff [2]: http://www.olsr.org/ [3]: https://www.open-mesh.org [4]: http://netjson.org/ [5]: http://wiki.ninux.org/ [6]: https://apps.db.ripe.net/search/query.html?searchtext=ninux&sources=RIPE_NCC#resultsAnchor [7]: https://guifi.net/ [8]: https://github.com/ninuxorg/nodeshot [9]: https://github.com/interop-dev/django-netjsongraph signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Name of some Ruby "application" packages
Hi, I am studying Ruby packaging guidelines. I would need to know some packages names that have been built following the "Applications" [1] rules, in order to read their spec file and upstream sources tree. Thank you for your time [1]: https://fedoraproject.org/wiki/Packaging:Ruby?rd=Packaging/Ruby#Applications signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
BOINC service does not write into log files
Hi, I am one of BOINC client maintainers.
I am trying to figure out why BOINC client 7.6.x does not write logs
inside /var/log/boinc{,_err}.log files so I started a very little thread
in BOINC forum [1], attaching boinc.service file and other stuff.
Reading guides about systemd's debugging, I decided to add
Environment=SYSTEMD_LOG_LEVEL=debug
to boinc-client.service file, then I have runned:
# journalctl -u boinc-client
but nothing useful come out, only a few BOINC regular messages, instead
#journalctl -b _PID=28226
returned
-- Logs begin at dom 2015-12-13 09:18:03 CET, end at sab 2016-05-21
17:26:39 CEST. --
mag 21 17:26:34 host boinc_client[28226]: 21-May-2016 17:26:34
Initialization completed
SELinux is in permissive mode.
I attach a few useful conf files and outputs. Don't look at Fedora's git
because certain files have not yet been updated.
=
# cat /usr/lib/systemd/system/boinc-client.service
[Unit]
Description=Berkeley Open Infrastructure Network Computing Client
Documentation=man:boinc(1)
After=network-online.target
[Service]
Type=forking
Nice=10
User=boinc
Group=boinc
PermissionsStartOnly=yes
WorkingDirectory=/var/lib/boinc
ExecStartPre=/usr/bin/touch /var/log/boinc.log /var/log/boinc_err.log
ExecStartPre=/bin/chown boinc:boinc /var/log/boinc.log
/var/log/boinc_err.log
ExecStart=/usr/bin/boinc_client --daemon --start_delay 1
ExecStop=/usr/bin/boinccmd --quit
ExecReload=/usr/bin/boinccmd --read_cc_config
ExecStopPost=/bin/rm -f /var/lib/boinc/lockfile
IOSchedulingClass=idle
Environment=LOGFILE=/var/log/boinc.log
Environment=ERRORLOG=/var/log/boinc_err.log
Environment=SYSTEMD_LOG_LEVEL=debug
[Install]
WantedBy=multi-user.target
=
=
# ls -latr /var/log/boinc*
-rw-r--r--. 1 boinc boinc 0 21 mag 15.58 /var/log/boinc.log
-rw-r--r--. 1 boinc boinc 0 21 mag 15.58 /var/log/boinc_err.log
=
=
An entry from top
25657 boinc 39 19 76756 36704 2088 R 64,7 0,2 9:49.40 wcgrid_mcm1_7.3
=
[1]: http://boinc.berkeley.edu/dev/forum_thread.php?id=11011
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
We often deal with upstream developers that bundle libraries in their code, so to make a package we have to debundle them, etc. This time, an upstream dev. asked me what he could do to make easier the work of packagers. In this case the software is python-netjsongraph [1] that bundles javascript-d3 library and that is being reviewd at [2] I think it would be nice to make a discussion even for non Python packages, so we can elaborate a sort of vademecum that a packager could show to upstreams when there is a collaboration between them. Have a nice day [1]: https://github.com/interop-dev/django-netjsongraph [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
Il 20/11/2016 21:38, Nico Kadel-Garcia ha scritto: >> I think it would be nice to make a discussion even for non Python >> packages, so we can elaborate a sort of vademecum that a packager >> could show to upstreams when there is a collaboration between them. >> >> Have a nice day > Most upstream developers are happy to work with segregating > components. A few... such as the awscli python package manager. > use cfode with very bleeding edge and destabilizing dependencies. Ok, concerning [1][2] (Python+ JavaScript), what would you suggest to the upstream (Federico Capoano), in order to make the work easier for both us and him? Thank you [1]: https://github.com/interop-dev/django-netjsongraph [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: state of advanced audio in Fedora
Recently Ardour 4 has been added to Fedora repositories (without video support due legal problems). You may want to give a look to it https://admin.fedoraproject.org/pkgdb/package/rpms/ardour4/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
Il 20/11/2016 21:38, Nico Kadel-Garcia ha scritto: >> I think it would be nice to make a discussion even for non Python >> packages, so we can elaborate a sort of vademecum that a packager >> could show to upstreams when there is a collaboration between them. >> >> Have a nice day > Most upstream developers are happy to work with segregating > components. A few... such as the awscli python package manager. > use cfode with very bleeding edge and destabilizing dependencies. Ok, concerning [1][2] (Python+ JavaScript), what would you suggest to the upstream (Federico Capoano), in order to make the work easier for both us and him? Thank you [1]: https://github.com/interop-dev/django-netjsongraph [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
IPFS and Fedora repositories
In past days I started playing with IPFS[1] "A peer-to-peer hypermedia protocol to make the web faster, safer, and more open." At [2] there is a very quick explanation about how IPFS works. The Freenode IRC channel #ipfs has more than 1000 users, so there is a great interest in it. By reading some articles, I noticed a nice paragraph of article [3], that made me wonder about IPFS usage on Fedora repositories: = Pinning Data to Save It IPFS has a notion of pinning content onto your IPFS node. When you “pin” content on your IPFS node, you’re adding the content’s hash (aka fingerprint) to the node’s pin set. As long as you have that hash in the node’s pin set, the node will keep a copy of the corresponding content on your machine. When you write your dataset into IPFS, your IPFS node will give you the hash for that dataset. You can then pass that hash to any of your peers and ask them to pin it on their IPFS nodes as well. As soon as you add a hash to your IPFS node’s pin set, the node will coordinate with peers on the IPFS network to pull a copy of the data onto your machine. = Since this mailing list is full of interesting opinions and ideas, I would like to hear your thoughts about what could be (in a far future) pros and cons of hypothetical IPFS based Fedora repositories. Thank you for your time [1]: https://ipfs.io/ [2]: https://ipfs.io/#how [3]: https://medium.com/@flyingzumwalt/instructions-for-saving-endangered-data-its-time-to-get-decentralized-23fb96aa8179#.bvs3eq5ag signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Packaging OnlyOffice Desktop Editors
I would like to package OnlyOffice Desktop Editors [1], but since it is the first time I see a Github tree very particular like this one, I don't know what effort would be required for packaging. What do you think about? [1]: https://github.com/ONLYOFFICE/DesktopEditors ___ 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
Re: Packaging OnlyOffice Desktop Editors
Il dom 6 ott 2019, 10:09 Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> ha scritto: > On 06.10.2019 09:08, Germano Massullo wrote: > > I would like to package OnlyOffice Desktop Editors [1] > > Packaging of Electron is not allowed: > https://fedoraproject.org/wiki/Electron The webpage should be improved because it does not contain the reasons why packaging of Electron is not allowed > > ___ 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
Re: Please welcome Julen (@jlanda) to the packager group
Welcome and thank you for your future contributions! ___ 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
bug 1767576 in fedora-review / mock and relative workarounds
Hello, in comment
https://bugzilla.redhat.com/show_bug.cgi?id=1767576#c7
I wrote my experience about fedora-review / mock bug that returns message
%{python3_pkgversion} expanded too early.
As workaround I renamed
python3-dateutil-2.8.0-2.fc30.src.rpm
to
pythonX-dateutil-2.8.0-2.fc30.src.rpm
but fedora-review fails and mock instead works. How can this happen?
fedora-review -rn pythonX-dateutil-2.8.0-2.el7.src.rpm -m epel-7-x86_64
messages:
=
$ cat /home/user/pythonX-dateutil/results/build.log
Mock Version: 1.4.21
Mock Version: 1.4.21
Mock Version: 1.4.21
ENTER ['do_with_status'](['bash', '--login', '-c', '/usr/bin/rpmbuild
-bs --target x86_64 --nodeps
/builddir/build/SPECS/pythonX-dateutil.spec'],
chrootPath='/var/lib/mock/epel-7-x86_64/root'env={'TERM': 'vt100',
'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf
"\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ',
'LANG': 'it_IT.UTF-8'}shell=Falselogger=timeout=0uid=1000gid=135user='mockbuild'nspawn_args=['--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf']unshare_net=TrueprintOutput=False)
Using nspawn with args ['--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf']
Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M',
'6a93f12b99554f5187ca6634dde022d3', '-D',
'/var/lib/mock/epel-7-x86_64/root', '-a', '--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf',
'--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash',
'--setenv=HOME=/builddir', '--setenv=HOSTNAME=mock',
'--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin',
'--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"',
'--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=it_IT.UTF-8',
'-u', 'mockbuild', 'bash', '--login', '-c', '/usr/bin/rpmbuild -bs
--target x86_64 --nodeps /builddir/build/SPECS/pythonX-dateutil.spec']
with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir',
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin',
'PROMPT_COMMAND': 'printf "\\033]0;\\007"', 'PS1':
' \\s-\\v\\$ ', 'LANG': 'it_IT.UTF-8'} and shell False
Creazione piattaforme target in corso: x86_64
Creazione per il target x86_64 in corso
Scritto: /builddir/build/SRPMS/pythonX-dateutil-2.8.0-2.el7.src.rpm
Child return code was: 0
ENTER ['do_with_status'](['bash', '--login', '-c', '/usr/bin/rpmbuild
-bb --target x86_64 --nodeps
/builddir/build/SPECS/pythonX-dateutil.spec'],
chrootPath='/var/lib/mock/epel-7-x86_64/root'env={'TERM': 'vt100',
'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf
"\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ',
'LANG': 'it_IT.UTF-8'}shell=Falselogger=timeout=0uid=1000gid=135user='mockbuild'nspawn_args=['--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf']unshare_net=TrueprintOutput=False)
Using nspawn with args ['--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf']
Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M',
'7fc50fbdd7ad47258797050e5baf2177', '-D',
'/var/lib/mock/epel-7-x86_64/root', '-a', '--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf',
'--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash',
'--setenv=HOME=/builddir', '--setenv=HOSTNAME=mock',
'--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin',
'--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"',
'--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=it_IT.UTF-8',
'-u', 'mockbuild', 'bash', '--login', '-c', '/usr/bin/rpmbuild -bb
--target x86_64 --nodeps /builddir/build/SPECS/pythonX-dateutil.spec']
with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir',
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin',
'PROMPT_COMMAND': 'printf "\\033]0;\\007"', 'PS1':
' \\s-\\v\\$ ', 'LANG': 'it_IT.UTF-8'} and shell False
Creazione piattaforme target in corso: x86_64
Creazione per il target x86_64 in corso
Esecuzione(%prep) in corso: /bin/sh -e /var/tmp/rpm-tmp.7EW5sc
+ umask 022
+ cd /builddir/build/BUILD
+ cd /builddir/build/BUILD
+ rm -rf python-dateutil-2.8.0
+ /usr/bin/gzip -dc /builddir/build/SOURCES/python-dateutil-2.8.0.tar.gz
+ /usr/bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd python-dateutil-2.8.0
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ iconv --from=ISO-8859-1 --to=UTF-8 NEWS
+ mv NEWS.new NEWS
+ exit 0
Esecuzione(%build) in corso: /bin/sh -e /var/tmp/rpm-tmp.nhj7aB
+ umask 022
+ cd /builddir/build/BUILD
+ cd python-dateutil-2.8.0
+ %py3_build
/var/tmp/rpm-tmp.nhj7aB: line 29: fg: no job control
Errori di compilazione RPM:
errore: Stato d'uscita errato da /var/tmp/rpm-tmp.nhj7aB (%build)
Stato d'uscita errato da /var/tmp/rpm-tmp.nhj7aB (%build)
Child return code was: 1
EXCEPTION: [Error()]
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/mockbuild/trace_decorator.py",
line 95, in trace
result = func(*args, **kw)
File "/usr/lib/python3.7/site-packages/mockbuild/util.py", lin
Valgrind and Fedora debuginfo: best GUI
I have to debug certain BOINC Manager problems (C++ language), and instead of importing and building the whole source tree in a project in a SDK like Eclipse, I want to simply use the debuginfos already available in Fedora repository. Concerning GDB usage I can do that with QtCreator. It attaches to and external running program, and I can easly see the sources. This seems to not happen with Valgrind on QtCreator: I can manage to start Valgrind and BOINC Manager, but I don't see anything. What do you suggest me to do to achieve using Valgrind in a GUI in a quick way? Thank you ___ 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
AMD ROCm
Hello, AMD ROCm - Open Source Platform for HPC and Ultrascale GPU Computing[1] is packaged by upstream only for RHEL/CentOS and Ubuntu. Is anybody working on packaging it for Fedora? If not, is anybody interested in setting up a team to work on it? Have a nice day [1]: https://rocm.github.io/ ___ 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
systemd unit file not updated on new package update
Hello, I am testing various changes in boinc-client systemd unit file. At every RPM package update, it happens really often that on a machine that installs the new RPM version, does not get the new systemd unit file version, so it is not updated. To successfully update the file, I have to remove the old one from /etc/systemd/system/ and reinstall the RPM file. How can this happen? Perhaps manual edits (on localhost) can prevent the file to be updated? Thank you ___ 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: AMD ROCm
Andreas Schneider [1] that is aware of Fedora community work on packaging ROCm stack, showed me his pending pull request [2] that "cleans up cmake so that the library can be correctly packaged for distributions. It also cleans up cmake as there are several things which should not be done in cmake." You may want to give a look to it. Best regards [1]: https://github.com/cryptomilk [2]: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/pull/25 ___ 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: systemd unit file not updated on new package update
I reply to your message in the bottom part, just let me explain how I got this situation, because my previous message lacked of informations. I have built and installed a new BOINC release with a systemd unit file patch, and I have noticed that the service behaviour has not changed. Therefore I runned # systemctl edit --full boinc-client and I have noticed that the BOINC systemd unit file has not been updated. So if I recall correctly, I searched for boinc-client.service file, and found it in /etc/systemd/system/boinc-client.service and /usr/lib/systemd/system/boinc-client.service then I remved the former, then runned # dnf reinstall boinc-client.rpm and everything seemed to be okay on both # systemctl edit --full boinc-client and general service behaviour. > First, packages should install unit files into /usr/lib/systed/systemd/. > Units in /etc are for system administrators and shouldn't be touched > by packages. BOINC client spec file should be okay https://src.fedoraproject.org/rpms/boinc-client/blob/master/f/boinc-client.spec I haven't installed the unit file under /etc. Perhaps this happened after # systemctl edit --full boinc-client usage? > Second, if the unit file is marked in .spec as %config(noreplace), > then it won't be touched/replaced on package upgrade. %config(noreplace) is not used for the systemd unit file > Third, you need to do `systemctl daemon-reload` when changing unit > files. Yes I know, I use it everytime I run # systemctl edit --full boinc-client Do you know if it should be runned also after BOINC package update (obviously a machine reboot will make this useless) > Manual edits as in `systemctl edit --full`? Plain `systemctl edit` > only creates addon snippets and does not copy the unit. Yes I know, I only used # systemctl edit --full boinc-client > Nevertheless, if admin placed unit in /etc, this unit has a priority > over the one in /lib installed by package. This is by design. I have never placed BOINC systemd unit file in /etc/systemd/system but I am wondering if "systemctl edit --full" can trigger the creation of such files under this folder ___ 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: systemd unit file not updated on new package update
Ok now everything it is clear. Thank you very much to everybody ___ 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
Fixing Wireguard spec file
This [1] is the Wireguard spec file from upstream Copr repo [2]. Wireguard will be included in kernel 5.0, but meanwhile we are using it as dkms. The only problem is that at every Wireguard upgrade, a manual action is required. For example now that I have installed 0.0.20190123, I have to remove the old /var/lib/dkms/wireguard/0.0.20181218/ folder in order to let # dkms autoinstall work. Otherwise I will get a === # dkms status Error! Could not locate dkms.conf file. File: /var/lib/dkms/wireguard/0.0.20181218/source/dkms.conf does not exist. === and wg-quick service unable to start. Do you have any idea about how the Wireguard spec file could be fixed in order to avoid this action having to be runned at every package update? Thank you [1]: https://copr-be.cloud.fedoraproject.org/results/jdoss/wireguard/fedora-29-x86_64/00839061-wireguard-dkms/wireguard-dkms.spec [2]: https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/ ___ 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: Fixing Wireguard spec file
Il giorno mar 29 gen 2019 alle ore 17:39 Nicolas Chauvet ha scritto: > There is a wireguard package maintained by Robert-André Mauchin on RPM > Fusion that at least... works. Ah I did not know that, thank you ___ 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: exiv2-0.27.0 coming to rawhide
Thank you Rex ___ 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: Fixing Wireguard spec file
Il giorno gio 31 gen 2019, 00:15 Joe Doss ha scritto: > Hey Germano, > > I have a working RPM that does not error out with Error! Could not locate > dkms.conf file if you want to test it out before I push it to copr. > Hi Joe, I can test it on next Wireguard snapshot release, actually I cannot reproduce an update action > ___ 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: Fixing Wireguard spec file
Joe, I found a machine on which I can reproduce the problem. I installed wireguard-dkms-0.0.20190123-2.fc29.noarch on top of wireguard-dkms-0.0.20190123-1.fc29.noarch but the machine while running # dkms autoinstall still returns Error! Could not locate dkms.conf file. File: /var/lib/dkms/wireguard/0.0.20181218/source/dkms.conf does not exist. Actually I am leaving this place, so I will have no longer access to this machine for a certain amount of time ___ 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
Nextcloud-client testers wanted
Hello, I need some testers for getting karma feedbacks about nextcloud-client 2.5.2 that is in updates-testing https://bodhi.fedoraproject.org/updates/?packages=nextcloud-client Thank you ___ 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: Nextcloud-client testers wanted
Hi Radka, could you please try using a new ~/.config/Nextcloud/ folder and see if this happens again? ___ 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
Writing C/C++ code to detect running desktop environment
I am working on implementing a piece of code that allows BOINC client [1] to detect the desktop environment used by the user (mainly GNOME, KDE Plasma, XFCE, LXDE/LXQT). This feature will be needed for various reason that are off topic. One idea is to use GDBus to scan DBus to detect the running d.e. What do you think about? Thank you [1]: https://github.com/BOINC/boinc/tree/master/client ___ 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: Writing C/C++ code to detect running desktop environment
Il giorno mer 29 mag 2019 alle ore 22:12 Stephen Gallagher ha scritto: > > On Wed, May 29, 2019 at 1:16 PM Kalev Lember wrote: > I realize you said that the reasons are off-topic, but in general I'd > recommend not making desktop-specific decisions at a high-level I need to retrieve user idle time. To achieve this I was using GDbus API of GLib/GIO to retrieve the systemd-logind IdleSinceHint DBus property, but I have been told that logind relies on desktop environment to pass the information to update this property. None of main desktop environments does it, so I am writing code that will interact with specific d.e. to retrieve user idle time. More infos at "[systemd-devel] interacting with logind to detect user idle time"[1] [1]: https://lists.freedesktop.org/archives/systemd-devel/2019-May/042496.html ___ 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: Writing C/C++ code to detect running desktop environment
A dubt about XDG_CURRENT_DESKTOP. Since boinc-client runs as a service with its own user, I don't think it will be able to read XDG_CURRENT_DESKTOP defined in other users sessions. Therefore IMHO I need another kind of solution ___ 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: Writing C/C++ code to detect running desktop environment
Il giorno mar 4 giu 2019 alle ore 17:31 Björn Persson ha scritto: > So the question isn't what desktop the user is using, but rather what > desktops, if any, other users on the machine are using. Well when I started the thread I had not thought that BOINC client service is running on a confined user. > Have you confirmed that you're able to query another user's desktop session > once > you know which desktop it is? I cannot read XDG_CURRENT_DESKTOP of other users. I am actually wondering if checking for specific executables [1] [2] would be the best idea [1]: like for example /usr/bin/plasmashell [2]: or scanning running processes ___ 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: Writing C/C++ code to detect running desktop environment
Il giorno mar 4 giu 2019 alle ore 19:00 Björn Persson ha scritto: I'll be surprised if you can do that > to another user's session without help from some privileged service. That is a very good question, thank you for pointing it out. I will let you know ___ 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
Missing debuginfos on service crash
Hello, BOINC client maintainer here. I made a new package version containing a patch. When I run BOINC client as system service, I will get crash errors on journalctl, errors like boinc[2543]: /usr/bin/boinc(+0x8b894)[0x5572ee5ac894]. By the way there are not symbols, like it does not care about installed debuginfo. What could I do? Thank you ___ 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
nextcloud-client 2.5: help for updating qt syslibs patch
Hi there. I am testing nextcloud-client 2.5 beta 1 [0], and I am in troubles with syslib patch[1]. This patch has been produced some time ago by previous owncloud-client maintainers, and I simply replicate it on every new release of the software client. By the way, on 2.5.0 this patch triggers some compilation errors [2] [3], whereas disabling the patch on compilation time, lets the compilation to be successfully completed [4]. Concerning the errors in [2][3], I made some attempts of fixing connect(this, &SharedTools::QtSingleApplication::messageReceived, this, &Application::slotParseMessage); put they only leaded to more deeper errors. Since I am not very confident with qt libs, I am looking for some suggestions about how to improve the patch file Thank you for your time [0]: https://copr.fedorainfracloud.org/coprs/germano/nextcloud-client-2.5 [1]: ** old version, for newer look at copr 2.5.0 srpm** https://src.fedoraproject.org/rpms/nextcloud-client/blob/master/f/nextcloud-client-2.4.0-syslibs.patch [2]: https://copr.fedorainfracloud.org/coprs/germano/nextcloud-client-2.5/build/788770/ [3]: https://copr-be.cloud.fedoraproject.org/results/germano/nextcloud-client-2.5/fedora-28-x86_64/00788770-nextcloud-client/build.log.gz [4]: https://copr.fedorainfracloud.org/coprs/germano/nextcloud-client-2.5/build/788739/ (temporarily disabled nextcloud-client-icon.patch too) ___ 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/CUJBHKFLX5HMRQBCLFNWGDCQLFPD57JQ/
Re: nextcloud-client 2.5: help for updating qt syslibs patch
During past weeks, co-maintainer FAS nonamedotc has made some other attempts to fix the problem, but he had no success. Can anybody please provide some hints about how we could proceed? Thank you very much ___ 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: nextcloud-client 2.5: help for updating qt syslibs patch
On 8/29/18 1:40 PM, Rex Dieter wrote: Germano Massullo wrote: During past weeks, co-maintainer FAS nonamedotc has made some other attempts to fix the problem, but he had no success. Can anybody please provide some hints about how we could proceed? Consider just using the bundled versions? That was our last resort ___ 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: package downgrades from f28 to f29
Il giorno mer 10 ott 2018 alle ore 13:58 Fabio Valentini ha scritto: > I seem to > remember that package versions should always be higher in newer fedora > releases (so there are no downgrades when upgrading from N to N+1). Is > this what is referred to as a "broken upgrade path"? Exactly ___ 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: package downgrades from f28 to f29
Il giorno mer 10 ott 2018 alle ore 15:46 Kamil Paral ha scritto: > That policy has been cancelled. Since the upgrade tools started doing > basically "dnf distrosync (--allowerasing)" for upgrades, the upgrade path > between distros stopped being a major issue and the policy has been dropped. Do we have an URL reference where we can read more about? ___ 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
Tune boinc-client spec file in order to ease debugging process
Hi everybody, I am debugging boinc-manager, and everytime I run $ gdb boincmgr (gdb) run then I trigger the crash, after running (gdb) thread apply all backtrace I obtain stuff like [...] argc= so I need help in tuning the boinc-client spec file[1] in order to avoid that (for example using gcc -O0). To begin, I started removing -DNDEBUG flag in order to re-enable the wxWidgets debug standard output. Thank you for your time [1]: https://src.fedoraproject.org/rpms/boinc-client/blob/master/f/boinc-client.spec#_167 ___ 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: What is Fedora?
22/06/23 11:06, Matthew Miller wrote: On Thu, Jun 22, 2023 at 08:44:13AM -, Michael J Gruber wrote: In the specific case of RHEL srpms, it makes life harder for EPEL packagers because you can't look at the source easily when they are problems between RHEL and EPEL packages. It matches well with RH's standard of shipping libraries without headers etc - it is easier for them and limits the scope of support contracts but makes upstream's life harder. EPEL packagers should have easy access to RHEL through the no-cost subscription program. Why should we keep contributing to EPEL? To be forced to use 16 free RHEL instances maximum? What is the advantage for us volunteer contributors? I mean, we did not do it for personal advantage, we did it to help us each other within the Enterprise Linux distros community, but this Red Hat move will kill the Enterprise Linux distros community, leaving only with RHEL, which is mostly a paid subscription distribution, let's call things with their proper name ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Java related] packaging Italian ID card middleware
Hello, I discussed the feasibility of packaging https://github.com/italia/cie-middleware-linux in Fedora devel Matrix channel with Cristian Le and xvitaly. With the help of Cristian Le I wrote the following [1] draft that will be used to open an upstream ticket to request various improvements to make it possible to include the software in the Fedora repository. We ended up needing the comment from Java package maintainers, if they see any other no-go. I am in particular concerned about https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_pre_built_dependencies Thank you [1]: https://germano.fedorapeople.org/canc/cie_middleware.md -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
It worths also mentioning that both the Windows and Mac OS versions do not contain any Java source. Moreover, the Windows version contains some C# sources https://github.com/italia/cie-middleware and the Mac OS version contains some Objective C sources https://github.com/italia/cie-middleware-macos They should have just used Qt libraries like the Estonian ID card software stack https://github.com/open-eid -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
Marián Konček wrote: [...]Note that my commits are dirty and I am not proposing them as changes, they show that it is possible to adopt Maven. So according to this, what would you recommend me to change in the point n.1 of my draft letter https://germano.fedorapeople.org/canc/cie_middleware.md = 1. please switch to CMake build system completely: some parts of the software need to be built through Eclipse, I.E. cie-pkcs11. CMake should be the only build system in the project. CMake will also enable CIE Middleware being built for all Linux distributions, Mac OS, Windows; = ?-- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
