Orphaned packages
I orphaned my packages, feel free to take them: https://src.fedoraproject.org/rpms/arpwatch https://src.fedoraproject.org/rpms/compat-guile18 https://src.fedoraproject.org/rpms/emacs https://src.fedoraproject.org/rpms/environment-modules https://src.fedoraproject.org/rpms/ghc-pipes-safe https://src.fedoraproject.org/rpms/iputils https://src.fedoraproject.org/rpms/logwatch https://src.fedoraproject.org/rpms/numad https://src.fedoraproject.org/rpms/perl-Sys-MemInfo https://src.fedoraproject.org/rpms/purple-plugin_pack https://src.fedoraproject.org/rpms/sgpio https://src.fedoraproject.org/rpms/xinetd -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GenericError: cannot update build
On Fri, Jan 3, 2020 at 12:37 PM Brad Bell wrote: > I do not understand this error message; i.e., I have no idea what the > cause is ? > > Looking at the informaiton for the build > https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178 > > The only failure message I see is > GenericError: cannot update build 1425936, state: COMPLETE > > The output on my screen is: > > cppad>fedpkg build > Building cppad-2020.0-1.fc31 for f31-candidate > Created task: 40063178 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178 > Watching tasks (this may be safely interrupted)... > 40063178 build (f31-candidate, > /rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): free > 40063178 build (f31-candidate, > /rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): free -> > open (buildvm-05.phx2.fedoraproject.org) >40063191 buildArch (cppad-2020.0-1.fc31.src.rpm, ppc64le): open > (buildvm-ppc64le-14.ppc.fedoraproject.org) >40063189 buildArch (cppad-2020.0-1.fc31.src.rpm, x86_64): open > (buildvm-32.phx2.fedoraproject.org) >40063187 buildArch (cppad-2020.0-1.fc31.src.rpm, armv7hl): open > (buildvm-armv7-17.arm.fedoraproject.org) >40063188 buildArch (cppad-2020.0-1.fc31.src.rpm, i686): open ( > buildhw-09.phx2.fedoraproject.org) >40063192 buildArch (cppad-2020.0-1.fc31.src.rpm, s390x): free >40063190 buildArch (cppad-2020.0-1.fc31.src.rpm, aarch64): free >40063179 buildSRPMFromSCM > (/rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): closed >40063192 buildArch (cppad-2020.0-1.fc31.src.rpm, s390x): free -> > open > (buildvm-s390x-24.s390.fedoraproject.org) >40063190 buildArch (cppad-2020.0-1.fc31.src.rpm, aarch64): free -> > open > (buildvm-aarch64-06.arm.fedoraproject.org) >40063192 buildArch (cppad-2020.0-1.fc31.src.rpm, s390x): open > (buildvm-s390x-24.s390.fedoraproject.org) -> closed >0 free 6 open 2 done 0 failed >40063188 buildArch (cppad-2020.0-1.fc31.src.rpm, i686): open > (buildhw-09.phx2.fedoraproject.org) -> closed >0 free 5 open 3 done 0 failed >40063189 buildArch (cppad-2020.0-1.fc31.src.rpm, x86_64): open > (buildvm-32.phx2.fedoraproject.org) -> closed >0 free 4 open 4 done 0 failed >40063191 buildArch (cppad-2020.0-1.fc31.src.rpm, ppc64le): open > (buildvm-ppc64le-14.ppc.fedoraproject.org) -> closed >0 free 3 open 5 done 0 failed >40063190 buildArch (cppad-2020.0-1.fc31.src.rpm, aarch64): open > (buildvm-aarch64-06.arm.fedoraproject.org) -> closed >0 free 2 open 6 done 0 failed >40063187 buildArch (cppad-2020.0-1.fc31.src.rpm, armv7hl): open > (buildvm-armv7-17.arm.fedoraproject.org) -> closed >0 free 1 open 7 done 0 failed > 40063178 build (f31-candidate, > /rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): open > (buildvm-05.phx2.fedoraproject.org) -> FAILED: GenericError: cannot > update build 1425936, state: > COMPLETE >0 free 0 open 7 done 1 failed > > 40063178 build (f31-candidate, > /rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664) failed > cppad> > I have already filed https://pagure.io/fedora-infrastructure/issue/8496. It may not be obvious from the description, but it's the same problem. -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemtap doesn't run
On Fri, Sep 6, 2019 at 10:37 PM Mark Wielaard wrote:
> Hi Jan,
>
> CC systemtap upstream list, because I think this is not a great error
> message.
>
> On Fri, 2019-09-06 at 09:53 +0200, Jan Synacek wrote:
> > I'm trying to run systemtap on F29 and I'm getting the following
> > error:
> >
> > $ sudo stap -v journal.stap
> > Pass 1: parsed user script and 491 library scripts using
> > 355824virt/129076res/9628shr/119256data kb, in 290usr/40sys/334real ms.
> > semantic error: while resolving probe point: identifier 'process' at
> > journal.stap:1:7
> > source: probe
> >
> process("/usr/lib/systemd/systemd-journald").function("dispatch_message_real")
> > {
> > ^
> >
> > semantic error: no match (similar functions: read, free, getenv,
> page_size,
> > safe_atoi)
> >
> > So, 'process' is not a valid identifier? There seems to be something
> wrong
> > with the basic systemtap installation. I do have matching debuginfo for
> > both kernel and systemd installed. Running stap-prep only wants to
> install
> > kernel-debuginfo.
> >
> > How do I make this basic use-case work?
>
> It is a bit hard to say, because you didn't include journal.stap.
> But I can replicate what you get with:
>
> stap -v -e 'probe
> process("/usr/lib/systemd/systemd-journald").function("dispatch_message_real")
> { log ("hit"); }'
>
> You get that error message if stap cannot find that function symbol.
> So first that ^ carrot should really not be at "process", but at
> "function" (or really "dispatch_message_real").
>
> stap really should tell you how to get that symbol. By installing the
> matching debuginfo package.
>
Right, so this is really the problem. The error message is simply wrong
plus it doesn't say that the debug symbols actually don't match.
$ rpm -q systemd systemd-debuginfo
systemd-239-13.gitf4afb95.fc29.x86_64
systemd-debuginfo-239-3.fc29.x86_64
For some reason, I thought that the debuginfo matched the systemd version.
Sorry about the misinformation. The fact that dnf considers these two
versions a match and doesn't install the correct version is another issue.
Thank you for pointing me to the right direction.
Regards,
--
Jan Synacek
Software Engineer, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
systemtap doesn't run
Hi,
I'm trying to run systemtap on F29 and I'm getting the following error:
$ sudo stap -v journal.stap
Pass 1: parsed user script and 491 library scripts using
355824virt/129076res/9628shr/119256data kb, in 290usr/40sys/334real ms.
semantic error: while resolving probe point: identifier 'process' at
journal.stap:1:7
source: probe
process("/usr/lib/systemd/systemd-journald").function("dispatch_message_real")
{
^
semantic error: no match (similar functions: read, free, getenv, page_size,
safe_atoi)
So, 'process' is not a valid identifier? There seems to be something wrong
with the basic systemtap installation. I do have matching debuginfo for
both kernel and systemd installed. Running stap-prep only wants to install
kernel-debuginfo.
How do I make this basic use-case work?
Regards,
--
Jan Synacek
Software Engineer, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Mass rebuild - emacs broken
On Thu, Jan 31, 2019 at 11:19 PM Richard W.M. Jones wrote: > > emacs isn't installable at the moment, so any package that needs emacs > fails to build, eg: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=32380321 > DEBUG util.py:490: BUILDSTDERR: Error: DEBUG util.py:490: BUILDSTDERR: Problem: package emacs-1:26.1-7.fc30.x86_64 requires libMagickCore-6.Q16.so.6()(64bit), but none of the providers can be installed DEBUG util.py:490: BUILDSTDERR: - package emacs-1:26.1-7.fc30.x86_64 requires libMagickWand-6.Q16.so.6()(64bit), but none of the providers can be installed DEBUG util.py:490: BUILDSTDERR: - conflicting requests DEBUG util.py:490: BUILDSTDERR: - nothing provides libwmflite-0.2.so.7()(64bit) needed by ImageMagick-libs-1:6.9.10.23-1.fc30.x86_64 Looks like a broken ImageMagick to me. -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The "see-also" field in bugzilla
On Tue, Jan 15, 2019 at 11:59 AM Emmanuel Seyman wrote: > * Ankur Sinha [15/01/2019 10:21] : > > > > I've commented there also, but I'd like to learn how others go about it > > without "see-also". > > Is there anything you did with "see-also" that you can't do with > the "External Trackers" feature? Unless I'm missing something, you have to use "External Trackers" on both sides. With "SeeAlso", you specified it in one bugzilla and it automatically showed in the referenced one. Also, linking two bugzillas together, because they are similar, or simply to "also see" something that might be related, can hardly be called external tracking. -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Buildroot broken in Rawhide
I got several FTBFS bug reports, the logs of which look like this: + make 'CFLAGS=-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 -std=gnu99' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lpthread -lrt -lm' cc -MM -DDEPS_RUN -I. numad.c > .depend.X && mv .depend.X .depend /bin/sh: cc: command not found I consider that a broken buildroot. -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FX2ONEFMTIDUPQLWTO3TR7S74J6XTVXP/
Re: glibc-headers is missing rpc/rpc.h in rawhide
On Thu, Mar 15, 2018 at 11:43 AM, Dan Horák <d...@danny.cz> wrote: > On Thu, 15 Mar 2018 11:30:32 +0100 > Jan Synacek <jsyna...@redhat.com> wrote: > >> Did I miss something? The xinetd package cannot be built because of >> that. > > https://fedoraproject.org/wiki/Changes/SunRPCRemoval So I missed something. Thank you for pointing me to this! Cheers, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
glibc-headers is missing rpc/rpc.h in rawhide
Did I miss something? The xinetd package cannot be built because of that. Cheers, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Broken rawhide buildroot/tools?
On Tue, Mar 13, 2018 at 10:14 AM, Emmanuel Seyman <emman...@seyman.fr> wrote: > * Jan Synacek [13/03/2018 09:59] : >> >> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25678436 > > From the root.log: > > DEBUG util.py:439: No matching package to install: > 'NetworkManager-glib-devel' Never mind, I'm blind. Thanks! -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Broken rawhide buildroot/tools?
Hi, I was trying to update pidgin, but the package doesn't build and it doesn't seem to be a packaging problem to me [1]. What's happening? [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25678436 -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ANNOUNCE] 7 applications written in Rust are available in Rawhide
On Tue, Nov 28, 2017 at 10:20 AM, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > On Tue, Nov 28, 2017 at 09:57:50AM +0100, Jan Synacek wrote: >> On Mon, Nov 27, 2017 at 6:38 PM, Igor Gnatenko >> <ignatenkobr...@fedoraproject.org> wrote: >> > snip >> >> I kind of wonder... What is so special about them that they deserve a >> big announcement like this? > > It wasn't possible to before. See > https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_and_libraries. Right, I didn't know that. I'm quite rusty when it comes to keeping up with changes. Cheers, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ANNOUNCE] 7 applications written in Rust are available in Rawhide
On Mon, Nov 27, 2017 at 6:38 PM, Igor Gnatenko <ignatenkobr...@fedoraproject.org> wrote: > snip I kind of wonder... What is so special about them that they deserve a big announcement like this? -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Font rendering and blurry fonts
On Thu, Aug 10, 2017 at 4:04 PM, Matthew Miller <mat...@fedoraproject.org> wrote: > On Thu, Aug 10, 2017 at 11:39:30AM +0200, Jan Synacek wrote: >> > Bug 1469712 - font antialiasing/hinting is not working on Fedora 26 >> > https://bugzilla.redhat.com/show_bug.cgi?id=1469712 >> Cheers, the solution from #1470509 did the trick. I'm quite puzzled as >> to why people prefer looking at the blurred fonts, though. > > I don't prefer blurred fonts, but I prefer more-correct letter forms > and nicer overall appearance of the page. Yes, I agree, but that's not what I see on my screen. Even if what I see is "more correct" by some measure, it's still blurry and hurting my eyesight. On the other hand, I totally understand that on some people's displays the result might actually look better. Also, my eyes are quite picky when it comes to staring at stuff for long periods of time. -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Font rendering and blurry fonts
On Thu, Aug 10, 2017 at 10:20 AM, Tomasz Torcz <to...@pipebreaker.pl> wrote: > On Thu, Aug 10, 2017 at 09:25:41AM +0200, Jan Synacek wrote: >> Hi, >> >> something changed between F24 and F26 (even F25) regarding font >> rendering and I can't figure out what it is. On F24, fonts were crispy >> clear with full hinting and antialiasing. On F25+, fonts are quite >> blurry even with the same hinting and antialiasing settings. I'm using >> XFCE and didn't change any settings. I didn't upgrade, but reinstalled >> F26. I would like to fix this because it's killing my eyes. Any idea >> what has changed or what to install/remove/reconfigure to bring the >> old rendering back? > > See bugs like > > Bug 1470509 - freetype/harfbuzz fc25->fc26 turns to ugly rendering > https://bugzilla.redhat.com/show_bug.cgi?id=1470509 > > Bug 1469712 - font antialiasing/hinting is not working on Fedora 26 > https://bugzilla.redhat.com/show_bug.cgi?id=1469712 Cheers, the solution from #1470509 did the trick. I'm quite puzzled as to why people prefer looking at the blurred fonts, though. Thanks again, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Font rendering and blurry fonts
Hi, something changed between F24 and F26 (even F25) regarding font rendering and I can't figure out what it is. On F24, fonts were crispy clear with full hinting and antialiasing. On F25+, fonts are quite blurry even with the same hinting and antialiasing settings. I'm using XFCE and didn't change any settings. I didn't upgrade, but reinstalled F26. I would like to fix this because it's killing my eyes. Any idea what has changed or what to install/remove/reconfigure to bring the old rendering back? Cheers, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Emacs build fails in Rawhide on ppc64le
I'm trying to build Emacs in Rawhide and this is what I get from the logs [1]: ... CCLD temacs /usr/lib/gcc/ppc64le-redhat-linux/7/../../../../lib64/libwebkit2gtk-4.0.so: undefined reference to `std::__once_callable@GLIBCXX_3.4.11' /usr/lib/gcc/ppc64le-redhat-linux/7/../../../../lib64/libwebkit2gtk-4.0.so: undefined reference to `std::__once_call@GLIBCXX_3.4.11' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:596: temacs] Error 1 ... Did the C++ library change and webkit wasn't rebuilt? I did another build of the same source rpm in F26 and everything went successfully. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=20592574 Cheers, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: git - wrong paths in documentation files
On Mon, Jul 17, 2017 at 8:45 PM, Petr Stodulka <pstod...@redhat.com> wrote: > > Hi folks, > I am looking at the #1357438 BZ about broken links to "How to*" doc files and > I am thinking, > about the best solution of this. Problem is with using of %doc macro, which > moves/copies > doc files to specific directories of each subpackage. However the Makefile > expects that will > be used just one directory, where all documentation will be included. > > It can be fixed basically in two ways: > > 1) Do not use %doc macro and keep all Doc files under common directory, >e.g. /usr/share/doc/git/ > ignoring the sub-package that install specific doc files. Yes, please. Since versioned docs are not used anymore, this is makes perfect sense, at least to me. Cheers, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: In need of C++ gurus
On Mon, Feb 20, 2017 at 9:27 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Mon, Feb 20, 2017 at 09:15:46AM +0100, Jan Synacek wrote: >> Hi, >> >> warzone2100 fails to build [1] and I have no idea how to fix that. >> Most of the errors are: >> >> main_sdl.cpp:79:13: error: expected unqualified-id before '__attribute__' >> static std::vector displaylist; // holds all our possible >> display lists >> ^ >> main_sdl.cpp:117:29: error: cannot convert 'bool' to '__vector(4) >> __bool int' in initialization >> static bool mouseInWindow = true; >> ^~~~ >> main_sdl.cpp:148:22: error: cannot convert 'bool' to '__vector(4) >> __bool int' in initialization >> bool GetTextEvents = false; >> ^ >> >> Could someone point me in the right direction? I've looked at [2], but >> that doesn't seem to help much in this case. > > That looks like C++ and altivec.h on PowerPC. altivec.h changes the > meaning of bool and vector keywords, so it is essential in what order > and what mode you include it if you really need it (easiest is of course > not include it at all). In general, for the non-ISO modes (i.e. > -std=gnu++98, -std=gnu++11, -std=gnu++14, -std=gnu++17 etc.) altivec.h > and preprocessor uses for these two context sensitive preprocessing, which > usually works with most of the C++ code, while if you compile in strict ISO > modes (-std=c++98, -std=c++11, -std=c++14, -std=c++17 etc.), then altivec.h > redefines vector and bool to the altivec.h stuff, so in that case you must > not include any standard C++ headers after including altivec.h and avoid > bool/vector or #undef them if you want the standard C++ meaning of those > (bool keyword and std::vector). > > So if you are using -std=c++* mode, easiest fix is to change it to > -std=gnu++* mode. Otherwise you need to provide more details. Thanks Dan and Jakub! There was a "-std=c++11" hidden in the configure, it was there because of some weird reason and simply removing it helped. -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
In need of C++ gurus
Hi, warzone2100 fails to build [1] and I have no idea how to fix that. Most of the errors are: main_sdl.cpp:79:13: error: expected unqualified-id before '__attribute__' static std::vector displaylist; // holds all our possible display lists ^ main_sdl.cpp:117:29: error: cannot convert 'bool' to '__vector(4) __bool int' in initialization static bool mouseInWindow = true; ^~~~ main_sdl.cpp:148:22: error: cannot convert 'bool' to '__vector(4) __bool int' in initialization bool GetTextEvents = false; ^ Could someone point me in the right direction? I've looked at [2], but that doesn't seem to help much in this case. [1] https://bugzilla.redhat.com/attachment.cgi?id=1254868 [2] https://gcc.gnu.org/gcc-7/porting_to.html Cheers, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Rust SIG
On Mon, Jan 30, 2017 at 9:03 AM, Igor Gnatenko <ignatenkobr...@fedoraproject.org> wrote: > Hello everybody, > > we are establishing new SIG for Rust[0]. Feel free to join us on IRC > (#fedora-rust) and/or Mailing List (r...@lists.fedoraproject.org). > > Help with improving our wiki page is very welcomed ;) > > [0] https://fedoraproject.org/wiki/SIGs/Rust Hi, I have a couple of questions. The description on the SIG page says: "This includes packaging Rust libraries and applications, setting and improving standards for packaging them as RPM's and maintaining Rust packages for Fedora." Isn't packaging Rust libraries waste of time? Cargo does a great job taking care of the libraries / dependencies. How is packaging Rust applications different from packaging any compiled (to ELF) applications? Apart from having the correct runtime, of course. Cheers, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Critpath flags on Emacs and Guile
Why were critpath flags set on Emacs and Guile? Cheers, -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fedpkg local --noclean?
On Thu, Oct 20, 2016 at 4:33 AM, Christopher <ctubb...@fedoraproject.org> wrote: > Is it possible to pass rpmbuild options like --noclean to `fedpkg local`? If > so, I can't seem to figure out how. AFAIK no, at least on F24. For local builds, you get far more control using plain mock -n (and/or --no-cleanup-after). -- Jan Synacek Software Engineer, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: g++ __VA_ARGS__ error
On Mon, Jul 11, 2016 at 2:22 PM, Jonathan Wakely
<jwak...@fedoraproject.org> wrote:
> On 11/07/16 13:16 +0100, Daniel P. Berrange wrote:
>>
>> On Mon, Jul 11, 2016 at 02:09:24PM +0200, Jan Synacek wrote:
>>>
>>> Hello,
>>>
>>> I'm trying to compile the latest version of Warzone2100 on rawhide,
>>> but I'm getting this error:
>>>
>>> g++ -DHAVE_CONFIG_H -I. -I.. -DYY_NO_INPUT -D_REENTRANT
>>> -I/usr/include/SDL2 -I/usr/include/libpng16 -I/usr/include/AL
>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DNDEBUG
>>> -DWZ_DATADIR="\"/usr/share/warzone2100\""
>>> -DLOCALEDIR="\"/usr/share/locale\"" -I.. -I../3rdparty
>>> -I../3rdparty/quesoglc -I/usr/include/libdrm-g -Wno-enum-compare
>>> -Wall -Wextra -Wno-unused-parameter -Wno-sign-compare -Wcast-align
>>> -Wwrite-strings -Wpointer-arith -Wno-format-security
>>> -I/usr/include/qt5/QtWidgets -I/usr/include/qt5
>>> -I/usr/include/qt5/QtGui -I/usr/include/qt5
>>> -I/usr/include/qt5/QtScript -I/usr/include/qt5
>>> -I/usr/include/qt5/QtCore -I/usr/include/qt5 -O2 -g -pipe -Wall
>>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>>> -fstack-protector-strong --param=ssp-buffer-size=4
>>> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>>> -m64 -mtune=generic -fPIC -std=c++11 -fstack-protector -c -o
>>> geometry.o geometry.cpp
>>> In file included from ../lib/framework/frame.h:44:0,
>>> from ../lib/framework/wzapp.h:24,
>>> from frontend.cpp:27:
>>> frontend.cpp: In function 'void startCampaignSelector()':
>>> ../lib/framework/string_ext.h:178:74: error: format not a string
>>> literal and no format arguments [-Werror=format-security]
>>> #define ssprintf(dest, ...) snprintf((dest), sizeof(dest), __VA_ARGS__)
>>>
>>> Could someone who understands g++ please advise how to fix this? I
>>> don't quite understand why it doesn't work.
>>
>>
>> It means the code calling this ssprintf() macro is passing a variable,
>> instead of a literal string. This is potentially unsafe as the compiler
>> can't validate that the string data in this variable contains format
>> arguments that are compatible with the __VA_ARGS__ passed at the same
>> time. This is quite commonly hit when people do not actually have any
>> variadic args at all, and just want to print out the string variable
>> as-is with no interpolation. The fix is usually to add a plain "%s"
>> format arg.
>>
>> eg if you have a varaible 'char *somemsg' which contains the data
>> to print and you're calling ssprintf(somemsg), then you would want
>> to change it to ssprintf("%s", somemsg). This avoids any danger if
>> 'somemsg' could itself potentailly contain % format specifies
>
>
> Looks like it's coming from here:
> https://github.com/Warzone2100/warzone2100/blob/master/src/frontend.cpp#L381
>
> So the fix would be:
>
> ssprintf(hackList[i], "%s", list[i].name.toUtf8().constData());
Yep, that''s it, I didn't realize that.
My thanks to everyone!
--
Jan Synacek
Software Engineer, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
g++ __VA_ARGS__ error
Hello, I'm trying to compile the latest version of Warzone2100 on rawhide, but I'm getting this error: g++ -DHAVE_CONFIG_H -I. -I.. -DYY_NO_INPUT -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/libpng16 -I/usr/include/AL -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DNDEBUG -DWZ_DATADIR="\"/usr/share/warzone2100\"" -DLOCALEDIR="\"/usr/share/locale\"" -I.. -I../3rdparty -I../3rdparty/quesoglc -I/usr/include/libdrm-g -Wno-enum-compare -Wall -Wextra -Wno-unused-parameter -Wno-sign-compare -Wcast-align -Wwrite-strings -Wpointer-arith -Wno-format-security -I/usr/include/qt5/QtWidgets -I/usr/include/qt5 -I/usr/include/qt5/QtGui -I/usr/include/qt5 -I/usr/include/qt5/QtScript -I/usr/include/qt5 -I/usr/include/qt5/QtCore -I/usr/include/qt5 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fPIC -std=c++11 -fstack-protector -c -o geometry.o geometry.cpp In file included from ../lib/framework/frame.h:44:0, from ../lib/framework/wzapp.h:24, from frontend.cpp:27: frontend.cpp: In function 'void startCampaignSelector()': ../lib/framework/string_ext.h:178:74: error: format not a string literal and no format arguments [-Werror=format-security] #define ssprintf(dest, ...) snprintf((dest), sizeof(dest), __VA_ARGS__) Could someone who understands g++ please advise how to fix this? I don't quite understand why it doesn't work. Cheers, -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: pidgin, was Re: Orphaned Packages in branched (2016-05-03)
On Tue, May 3, 2016 at 10:22 PM, Paul Wouters <p...@nohats.ca> wrote: > On Tue, 3 May 2016, opensou...@till.name wrote: > >> libsilcorphan, cicku, nosnilmot 9 weeks ago > > >> Depending on: libsilc (12), status change: 2016-02-26 (9 weeks ago) >> pidgin (maintained by: jsynacek, itamarjp, jskarvad, mcrha, >> nosnilmot) >> libpurple-2.10.12-2.fc24.i686 requires libsilc-1.1.so.2, >> libsilcclient-1.1.so.3 >> pidgin-2.10.12-2.fc24.src requires libsilc-devel = >> 1.1.10-15.fc24 > > > [ list of pidgin plugins including the one I maintain ] > > I got a few of these warnings in the last few weeks and I'd like those > to stop :) > > Is there any interest in supporting SILC? It's an old encryption chat > protcol that I never used or never heard of someone using. > > Do the pidgin maintainers want to take the package on, or recompile > pidgin without silc support so we can get pidgin of the death list? I've disabled silc support. -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 broken dependencies
On Tue, Mar 22, 2016 at 12:46 PM, José Matos <jama...@fc.up.pt> wrote: > On Tuesday, March 22, 2016 12:13:47 PM WET Jan Synacek wrote: >> Currently, it's not possible to update from F23 to F24 because of >> broken dependencies. >> >> # dnf update --releasever=24 --best --allowerasing > > Does it helps if instead of update/upgrade you use distro-sync? Yes, that performs the update without complaining. Why is that? > I have updated last week using the dnf system-upgrade method and it worked. I have updated too and it also worked. But now it seems to be broken. > The only issue was with pydot -> python2-pydot that does not work. That is in > Fedora 24 python2-pydot provides the same files/functionality of pydot in > Fedora 23 but it does not obsolete it. Cheers, -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F24 broken dependencies
Currently, it's not possible to update from F23 to F24 because of broken dependencies. # dnf update --releasever=24 --best --allowerasing Error: package firebird-libfbembed-2.5.5.26952.0-2.fc23.x86_64 requires libicuuc.so.54()(64bit), but none of the providers can be installed. package firefox-45.0.1-1.fc23.x86_64 requires libvpx.so.2()(64bit), but none of the providers can be installed. package gnome-abrt-1.2.2-1.fc23.x86_64 requires python(abi) = 3.4, but none of the providers can be installed. package webkitgtk3-2.4.10-1.fc23.x86_64 requires libwebp.so.5()(64bit), but none of the providers can be installed. package python3-dnf-1.1.7-2.fc23.noarch requires python(abi) = 3.4, but none of the providers can be installed. package dnf-1.1.7-2.fc23.noarch requires python3-dnf = 1.1.7-2.fc23, but none of the providers can be installed. package dnf-yum-1.1.7-2.fc23.noarch requires dnf = 1.1.7-2.fc23, but none of the providers can be installed. package python3-dnf-1.1.7-2.fc23.noarch requires python(abi) = 3.4, but none of the providers can be installed # dnf update --releasever=24 ... Install20 Packages Upgrade 1256 Packages Skip 265 Packages ... Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction check error: file /usr/lib64/libpython3.so from install of system-python-libs-3.5.1-7.fc24.x86_64 conflicts with file from package python3-libs-3.4.3-5.fc23.x86_64 file /usr/lib64/gstreamer-1.0/libgstopus.so from install of gstreamer1-plugins-base-1.7.90-2.fc24.x86_64 conflicts with file from package gstreamer1-plugins-bad-free-1.6.3-3.fc23.x86_64 -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd stopped building on rawhide
Jan Synáček <jsyna...@redhat.com> writes: > Hello, > > systemd rawhide builds started failing in koji [1]: > > In file included from src/shared/firewall-util.c:23:0: > /usr/include/linux/if.h:71:2: error: redeclaration of enumerator 'IFF_UP' > IFF_UP= 1<<0, /* sysfs */ > ^ > /usr/include/net/if.h:44:5: note: previous definition of 'IFF_UP' was here > IFF_UP = 0x1, /* Interface is up. */ > ^ > /usr/include/linux/if.h:72:2: error: redeclaration of enumerator > 'IFF_BROADCAST' > IFF_BROADCAST = 1<<1, /* __volatile__ */ > ^ > /usr/include/net/if.h:46:5: note: previous definition of 'IFF_BROADCAST' was > here > IFF_BROADCAST = 0x2, /* Broadcast address valid. */ > ^ > ... > > $ rpm -qf /usr/include/linux/if.h /usr/include/net/if.h > kernel-headers-4.3.4-300.fc23.x86_64 > glibc-headers-2.22-7.fc23.x86_64 > > Have there been any changes to these packages in regards to the include files? > > [1] https://kojipkgs.fedoraproject.org//work/tasks/8338/12698338/build.log Also note that systemd failed during the mass rebuild because of the same problem, which is really sad. What is even more sad is the line that has been added into the changelog. It says "Rebuilt for ", which is simply not true. -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new point of contact
Kevin Fenzi <ke...@scrye.com> writes: > ... > purple-plugin_pack -- A set of plugins for libpurple, pidgin, and finch ( > master f23 f22 ) Taken. -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Emacs 25 Copr repo
Haïkel <hgue...@fedoraproject.org> writes: > 2016-01-07 9:07 GMT+01:00 Jan Synacek <jsyna...@redhat.com>: >> Hello Emacs fans, >> >> in case you want to try the latest Emacs and don't want to build it >> yourselves... >> >> https://copr.fedoraproject.org/coprs/jsynacek/emacs-25/ >> > > Did you consider submitting a Feature proposal for F24? Nope, Emacs 25 hasn't been released yet. > Regards, > H. > >> Enjoy, >> -- >> Jan Synacek >> Software Engineer, Red Hat >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Poll: emacs.desktop or emacsclient.desktop?
Which one do you use? Having both is confusing, as noted in [1], so I'm planning to remove one of them. What do you think should be the default? Please, write what *you* think/use, not what you guess that other people might want to use. For me, it's emacs.desktop, since clicking the desktop icon is then simply consitent with the rest of the icons. The emacsclient behavior is just weird. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1175969 Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: emacs-filesystem
Michael Schwendt <mschwe...@gmail.com> writes: > On Mon, 04 Jan 2016 15:35:51 +0100, Jan Synacek wrote: > >> Hello, >> >> long time ago, there was a request to create the emacs-filesystem >> package [1], so other packages could drop their emacs-specific files >> there. I believe it was done the other way around... Those files are >> useless without emacs to begin with. I think packages that have emacs >> snippets / modes should have a "-emacs" subpackage (or something like >> that) that depends on emacs itself. > > Two observations: > > 1) Emacs extensions are to be put into emacs- subpackages, not -emacs. > It's in the %parent-%child naming guidelines. Note that sometimes this > is implemented as virtual package names, i.e. explicit Provides such as > those in desktop-file-utils. Ok. > 2) A dependency on emacs-filesystem is primarily for packages, which store > files in those directories, but which do _not_ need Emacs to be installed. > Splitting off emacs- subpackages is not always the most wise/convenient > choice. Any examples of such packages? I still can't imagine how storing emacs specific stuff into emacs directories without requiring emacs could be useful. Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: emacs-filesystem
Jonathan Underwood <jonathan.underw...@gmail.com> writes: > On 4 January 2016 at 14:35, Jan Synacek <jsyna...@redhat.com> wrote: >> ... >> Any comments? Maybe there are still people that were involved with the >> change? > > Those unaware of history are doomed to repeat it :) That's why I'm asking ;) > It previously was the case that packages that also shipped support > files for emacs were required to ship the emacs bits in a sub-package. > However, the result was that very few packagers actually complied, and > indeed some just shipped the emacs bits as %docs. > > The move to using emacs-filesystem (proposed by me) was a move to be > consistent with vim and xemacs practices. The packages you are talking > about are primarily not emacs add-ons, but packages that also ship a > couple of elisp files to provide auxillary emacs support if emacs is > present on the system. Pulling in the whole emacs stack in such cases > would be overkill. However, having the user have to install endless > emacs-foo packages just to install a few elisp files also seemed like > overkill. The emacs-filesystem approach was a happy compromise, and > already a widely used strategy in Fedora (see vim, xemacs etc). I > still think it's the best approach, personally, as splitting out all > these little elisp files into their own packages just increases > package metadata bloat. This is the explanation I was looking for, thank you! > Any change to the current situation would need to be agreed with the > FPC, and coordinated distro wide. Given that we're only now > approaching compliance with the current emacs add-on packaging > guidelines, I can imagine some resistance to the change you're > proposing. > > I don't see why there are "WTF moments" when emacs-filesystem i > installed - it contains a few directories, and nothing else. > > For info: > > https://fedoraproject.org/wiki/Packaging:Emacs Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
emacs-filesystem
Hello, long time ago, there was a request to create the emacs-filesystem package [1], so other packages could drop their emacs-specific files there. I believe it was done the other way around... Those files are useless without emacs to begin with. I think packages that have emacs snippets / modes should have a "-emacs" subpackage (or something like that) that depends on emacs itself. The following packages now depend on emacs-filesystem (I have omitted i686 variants for brevity): a2ps-0:4.14-28.fc23.x86_64 anthy-0:9100h-28.fc23.x86_64 asymptote-0:2.35-3.fc23.x86_64 autoconf-0:2.69-21.fc23.noarch bigloo-0:4.1a-9.2.fc23.x86_64 clisp-0:2.49-18.20130208hg.fc23.x86_64 cmake-0:3.3.2-1.fc23.x86_64 crm114-0:0-10.20100106.fc23.x86_64 cscope-0:15.8-12.fc23.x86_64 desktop-file-utils-0:0.22-5.fc23.x86_64 emacs-common-1:24.5-6.fc23.x86_64 emacs-pysmell-0:0.7.3-4.fc23.noarch ftnchek-0:3.3.1-21.fc23.x86_64 gambit-c-0:4.7.9-1.fc23.x86_64 git-0:2.5.0-4.fc23.x86_64 global-0:6.5.1-1.fc23.x86_64 jflex-0:1.6.1-2.fc23.noarch libidn-0:1.32-1.fc23.x86_64 librep-0:0.92.5-1.fc23.x86_64 mercurial-0:3.5.1-1.fc23.x86_64 mozc-0:2.17.2077.102-5.fc23.x86_64 ninja-build-0:1.6.0-1.fc23.x86_64 nodejs-tern-0:0.7.0-6.fc23.noarch perl-SystemPerl-0:1.344-2.fc23.x86_64 pypy-libs-0:4.0.0-3.fc23.x86_64 pypy3-libs-0:2.4.0-2.fc23.x86_64 ratpoison-0:1.4.8-2.fc23.x86_64 reposurgeon-0:3.29-1.fc23.noarch root-0:5.34.32-5.fc23.x86_64 rpmdevtools-0:8.6-2.fc23.noarch tpp-0:1.3.1-19.fc23.noarch uim-0:1.8.6-8.fc23.x86_64 why-0:2.35-9.fc23.x86_64 yast2-devtools-0:3.1.36-2.fc23.noarch I think it would be better that these packages had their emacs subpackages, instead of the other way around. Not only would that make more sense, but itw would also resolve the WTF moments when installing unrelated packages that suddenly require emacs-filesystem to be installed as a dependency. Any comments? Maybe there are still people that were involved with the change? [1] https://bugzilla.redhat.com/show_bug.cgi?id=661866 Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Help with building ruby bindings for notmuch package
Jonathan Underwood <jonathan.underw...@gmail.com> writes: > Hi, > > In the process of updating the notmuch package on rawhide, I am > hitting the following problem during building of the ruby bindings - > can any ruby aficionados help me out? Hi, see https://bugzilla.redhat.com/show_bug.cgi?id=1280245, the attached patch should answer your question. Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Failing builds on rawhide
Peter Robinson <pbrobin...@gmail.com> writes: > On Thu, Nov 12, 2015 at 12:47 PM, Peter Robinson <pbrobin...@gmail.com> wrote: >> On Thu, Nov 12, 2015 at 12:41 PM, Jan Synacek <jsyna...@redhat.com> wrote: >>> I'm getting this error: >>> >>> bash: /usr/bin/rpmbuild: No such file or directory >>> >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=11804093 >> >> I suspect that's due to python 3.5 being tagged in, it should be OK >> shortly, I'm keeping an eye on it. > > I think we should be good now, I resbumitted your task > > http://koji.fedoraproject.org/koji/taskinfo?taskID=11804206 Thank you! -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Failing builds on rawhide
I'm getting this error: bash: /usr/bin/rpmbuild: No such file or directory http://koji.fedoraproject.org/koji/taskinfo?taskID=11804093 Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
No space left on device: '/mnt/koji/work/tasks/...'
I can't 'fedpkg build' right now and I'm not sure where to file this. -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- 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: Pondering the Emacs add-on packaging situation
Jonathan Underwood jonathan.underw...@gmail.com writes: Hi, So, while filing a bunch of bugs against packages not complying with the Emacs add-on packaging guidelines, I started to think about the state of add-ons for Emacs [1]. Since those guidelines were put in place, Emacs has grown its own package manager (package.el, shipped with Emacs[2]), and now users can install something approaching 3000 packages from repositories like ELPA[3], MELPA[4] and Marmalade[5]. The Emacs package manager installs these add-on modules in the user's own directory by default, but it can also install them in a system wide directory. If you run Emacs as a regular user, you can install packages into system directories? That would be news to me. Why would anyone do that? My thoughts are currently that: 1) Fedora doesn't have the manpower to package large numbers of packages from these repositories and keep the Fedora packages up-to-date 2) It may be possible to write automation tools like elpa2rpm, melpa2rpm, marmalade2rpm to automate packging for Fedora from those repositories, but such tools don't yet exist. Even if they did, the repositories usually aren't the canonical upstream for the packages. Managing Emacs packages by the distribution makes, IMHO, no sense at all. Users can easily manage the packages themselves via Emacs' package.el user interface. 3) Even if we could generate rpm packages directly from the emacs package repos, package.el doesn't have any notion such as installed but inactive for packages, such that installing rpm packages of emacs packages would activate them for all system users, which is undesireable. Again, I'm not aware of how a regular user can install Emacs packages for all the users. If it can be done, you either have to have root privileges, or there is some kind of Fedora-specific polkit rule or something. So, I am not really sure what a good way forward is at this point. Certainly package.el could be extended to help us out in some ways, such as having a notion of installed and available but not active. But is it worth the effort? In my opinion, no. I will repeat myself: Emacs packages should be left for users to install, since it's very easy to do, and they can choose From stable/development versions. The whole issue is another case of competition between an application package managers (package.el) and system package management such as we have had to solve for perl, python, texlive etc etc. But it's not clear to me what a good solution would be for Emacs. I'd welcome any thoughts anyone has (especially Tom Tromey if he still reads this list). Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- 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: Pondering the Emacs add-on packaging situation
Jonathan Underwood jonathan.underw...@gmail.com writes: On 24 June 2015 at 08:01, Jan Synacek jsyna...@redhat.com wrote: Jonathan Underwood jonathan.underw...@gmail.com writes: So, I am not really sure what a good way forward is at this point. Certainly package.el could be extended to help us out in some ways, such as having a notion of installed and available but not active. But is it worth the effort? In my opinion, no. I will repeat myself: Emacs packages should be left for users to install, since it's very easy to do, and they can choose From stable/development versions. You could, but there's a difference. The python/perl packages (libraries) can easily turn out to be a mess, because they are part of a development environment. It also makes much more sense (to me, at least) to have them installed system-wide. (Not sure if my explanation is clear enough.) OK, thanks for your thoughts, very helpful. I'm glad I could help. Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- 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: Can't give package to another developer
Michael Schwendt mschwe...@gmail.com writes: On Wed, 29 Apr 2015 10:52:09 +0200, Jan Synacek wrote: I'm trying to give one of my packages (openldap) to another developer, but the online tool keeps saying that User is not in the packager group, which I believe is not true, because he is in the same Fedora groups as I am. Where can I report this? Cheers, Look up his account group membership at the following URL: https://admin.fedoraproject.org/accounts/user/view/USERNAME Replace USERNAME with his FAS username. Some packagers use multiple email addresses in bugzilla and multiple usernames for different places and don't remember the FAS username correctly in some cases. I did this before asking, but didn't realize that what I should specify as a new point of contact was the FAS username, not the email... Thank you! -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Can't give package to another developer
I'm trying to give one of my packages (openldap) to another developer, but the online tool keeps saying that User is not in the packager group, which I believe is not true, because he is in the same Fedora groups as I am. Where can I report this? Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- 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: Issue with yum/systemd?
Dave Johansen davejohan...@gmail.com writes: I posted this issue on the users mailing list but didn't get a response ( https://lists.fedoraproject.org/pipermail/users/2015-March/459083.html ), so I thought I'd try here. I did a yum remove on F21 and it hung after the 2nd of 8 .rpms and systemd has been using ~40% of the CPU since then. Here's the stacktrace from yum: #0 0xb76debac in __kernel_vsyscall () #1 0xb7510d03 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0xb6fa4842 in rpmScriptRun () from /lib/librpm.so.3 #3 0xb6f83c53 in runScript () from /lib/librpm.so.3 #4 0xb6f8434f in runInstScript () from /lib/librpm.so.3 #5 0xb6f8531b in rpmpsmRun () from /lib/librpm.so.3 #6 0xb6f9a3cb in rpmteProcess () from /lib/librpm.so.3 #7 0xb6fa1714 in rpmtsRun () from /lib/librpm.so.3 #8 0xb6fd0f0a in rpmts_Run () from /usr/lib/python2.7/site-packages/rpm/_rpm.so #9 0xb758a609 in PyCFunction_Call () from /lib/libpython2.7.so.1.0 #10 0xb754a645 in PyObject_Call () from /lib/libpython2.7.so.1.0 #11 0xb75e6f33 in PyEval_CallObjectWithKeywords () from /lib/libpython2.7.so.1.0 #12 0xb75616c6 in methoddescr_call () from /lib/libpython2.7.so.1.0 #13 0xb754a645 in PyObject_Call () from /lib/libpython2.7.so.1.0 #14 0xb75eb187 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #15 0xb75ecfe1 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #16 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #17 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #18 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #19 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #20 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #21 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #22 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #23 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #24 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #25 0xb75ee344 in PyEval_EvalCode () from /lib/libpython2.7.so.1.0 #26 0xb76078db in run_mod () from /lib/libpython2.7.so.1.0 #27 0xb7608d70 in PyRun_FileExFlags () from /lib/libpython2.7.so.1.0 #28 0xb760a163 in PyRun_SimpleFileExFlags () from /lib/libpython2.7.so.1.0 #29 0xb760a6c8 in PyRun_AnyFileExFlags () from /lib/libpython2.7.so.1.0 #30 0xb761c911 in Py_Main () from /lib/libpython2.7.so.1.0 #31 0x08048578 in main () It looks like yum is waiting on some process. Is there a way I can tell what the process is and why it hasn't returned yet? Any other ideas on how I can figure out what is going wrong? Thanks, Dave This is somewhat reminiscent of [1]. Any chance that the process that actually uses the cpu is dbus related? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1186018 Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- 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: Pidgin Lync-collab COPR
David Woodhouse dw...@infradead.org writes: I've *just* managed to commit the in-call DTMF support that has been kicking around for about 4 years! ... In the meantime though, any additional testing would be welcome... For the interested, this patch is now in F21 testing: https://admin.fedoraproject.org/updates/pidgin-2.10.11-2.fc21 -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- 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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
Marek Polacek pola...@redhat.com writes: To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek) have performed a test mass rebuild of rawhide (January 15th package list) using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from the list packages that fail for non-GCC related reasons. ... openldap-2.4.40-5.fc22.src.rpm Fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1191098 -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- 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: Removing (or trying to) BerkeleyDB from Fedora
Jan Staněk jsta...@redhat.com writes: Hi guys, as the new BerkeleyDB 6.x has a more restrictive license than the previous versions (AGPLv3 vs. LGPLv2), and due to that many projects cannot use it, perhaps it is time to get rid of it from Fedora for good - or at least trim down the list of packages dependent on it as much as possible. As the maintainer of openldap, I wouldn't mind too much switching to MDB as the default backend (in my understanding, it's preferred by the upstream as well). However, I *think* that many people still use it and wouldn't like the change much. If there are any openldap users, please, comment. Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- 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: Strange ssh / openldap linking problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/20/2014 03:33 PM, Richard W.M. Jones wrote: Well this bug has reappeared on my machine. openldap depends on openldap-devel. $ ll /usr/lib64/libldap* lrwxrwxrwx. 1 root root 10 Feb 25 22:59 /usr/lib64/libldap-2.4.so.2 - libldap.so -rwxr-xr-x. 1 root root 340608 Feb 4 09:08 /usr/lib64/libldap-2.4.so.2.10.2 lrwxrwxrwx. 1 root root 12 Feb 25 22:59 /usr/lib64/libldap_r-2.4.so.2 - libldap_r.so -rwxr-xr-x. 1 root root 365848 Feb 4 09:08 /usr/lib64/libldap_r-2.4.so.2.10.2 lrwxrwxrwx. 1 root root 23 Feb 25 23:09 /usr/lib64/libldap_r.so - libldap_r-2.4.so.2.10.2 lrwxrwxrwx. 1 root root 21 Feb 25 23:09 /usr/lib64/libldap.so - libldap-2.4.so.2.10.2 $ for f in /usr/lib64/libldap*; do echo -n $f comes from ; rpm -qf $f; done /usr/lib64/libldap-2.4.so.2 comes from openldap-2.4.39-2.fc20.x86_64 /usr/lib64/libldap-2.4.so.2.10.2 comes from openldap-2.4.39-2.fc20.x86_64 /usr/lib64/libldap_r-2.4.so.2 comes from openldap-2.4.39-2.fc20.x86_64 /usr/lib64/libldap_r-2.4.so.2.10.2 comes from openldap-2.4.39-2.fc20.x86_64 /usr/lib64/libldap_r.so comes from openldap-devel-2.4.39-2.fc20.x86_64 /usr/lib64/libldap.so comes from openldap-devel-2.4.39-2.fc20.x86_64 This breaks libguestfs when it happens. I've noticed that lots of people have hit this bug before: https://bugzilla.redhat.com/show_bug.cgi?id=240253 https://bugzilla.redhat.com/show_bug.cgi?id=248065 https://bugzilla.redhat.com/show_bug.cgi?id=249866 https://bugzilla.redhat.com/show_bug.cgi?id=447645 https://bugzilla.redhat.com/show_bug.cgi?id=460307 https://bugzilla.redhat.com/show_bug.cgi?id=693716 https://bugzilla.redhat.com/show_bug.cgi?id=1028557 It's obviously a longstanding packaging bug in openldap and I think it needs to be fixed. Rich. Thanks for the report. Let's continue in the bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=1028557 Cheers, - -- Jan Synacek Software Engineer, Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTK/ZHAAoJEL3BmMJQOtjB8XAP/0RRpksu+aka5VCFQv5PaM93 BiuDMYT5V7bznXFDoC3D+Qi5hYKdKLYb3FBGerNGOZZe/DoLhGx2dZF8fJjh+FRE XlcQw4/UHaA+7aYJKYYNgGbD6KTqHwXQZo1Hz06CK4T01Hp+eRzVYyXZTv8FD9Od 47ztfeHwd52zQ6Fe2JlJYj4D5d+KxMmYJkwFQAuSrwUDJJppoZ/Z2QWf2tbFZJ3V etCRleB3cPueE4xcmVsDWrwxj+wE5x2ybbpfh2bA+WhSuf56V8qRRN+RZoQRhm3B m63uDw/ItHuVzf/t7ym69+FynkyvnkOqOCvM0jF/gwNUJbuFaG2GiCjPiHLps1hl ooSMaPgHYWbDdcl29IhJaD5qn1gaplhvH2LO+yfGIj7OwbeHN99GVyxg+0VMww0R dSRhiwlyv14S700o3KDSvQ5qhHUOhdBgJRFlericznw70z5X8gju1xYcenkarzIX ec/YOEkPFdw62zoih6UyByVLHKRTuPqapL9qQKwTc/fNM6q8ljQGjLlCebCeeDGc m/J85dWmEpW2MimFDRBKksRKzqYfJ2A12RJo6snF5y7Xf/rfl5KfFkaUYzd1dEdz Lfa1k/7Fl5SaA8QM868pL8zTPHIgHtu0FVQzhbIQlT0aOaOTJZ2zQE8mSSE+pDsA hzBuKUGeL656j/r2Klwc =pvuB -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Package takeover request - pidgin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2014 01:32 PM, Jan Synacek wrote: Hello, I've been trying to contact Stu Tomlinson for a while now -- in a bugzilla [1] and by mail. Anybody know how to contact him? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1058220 Cheers, As per [1], item 5., this is my request to take over the package. [1] http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Outline - -- Jan Synacek Software Engineer, Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTAfXEAAoJEL3BmMJQOtjBhb4P/3LgfJ4d+uLWItSrUlJRFLMp K4ChA94b21XvVG1aX8HYb6/BEefrbivsHHsiB0l1oJwufMg6HJiLj+QujwF8ZiHo e29olP82QrHdWdEDb+69+jbA+vCDzP7hgAEDUDcjB8/NjvshuYBM77VyncLTXZZ3 NVDSfq8st/zMxTSN/01EJjwOvQwS+chKq8VL0mYNPMFqdciczgtt0TFYYl68Uns7 d/M6syyPjhXMpMjt6ETqgwgrzJ0JPbR5n8joAOKaaFJcuvEbxsBoYQiezKJ0+0Za T8eZOtSmzhDVJ+FotDsGFpxBoDiAL5k9vjXvuRzOfrh5FkTDlkPpqwrjHrFsnmHK tyPeBnxnMEsBqHNh+CFS8v/vYxh5n1hL5h9O183BsQJTAS2xOi42HaV5KY3NK6Li DWapcjp4bAYwJjuRoU4pY1yx+l/IWS3QhX5zXfQnTPaTPG/eKm5rUi5HhuAbmxdy ExEsiEhjR60vP8NtAmvwR89xWK5fh70XrUnPI/ZZ7Njr5pr278dRIqUn2nepad5D ZqFuCIMiykwVLR6BaRPKCxMeH0Psy+RAUP2fFzpC4QSr6Wfg69CbIbT1Fe/CMQxD C5cnwIS+4+Rjv9svnSYnLU6KeoOimGwBDL4/C6rLKne7EUvtSl5KkH4E09O8GvJv R40WehJUqM6XV4nVHhpA =dKCk -END PGP SIGNATURE- -- 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: Package takeover request - pidgin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2014 01:57 PM, Stu Tomlinson wrote: Jan, On Mon, Feb 17, 2014 at 11:43 AM, Jan Synacek jsyna...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2014 01:32 PM, Jan Synacek wrote: Hello, I've been trying to contact Stu Tomlinson for a while now -- in a bugzilla [1] and by mail. Anybody know how to contact him? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1058220 Cheers, As per [1], item 5., this is my request to take over the package. [1] http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Outline Many apologies for missing your bug email. As you can tell I have had no time to contribute to Fedora in a long time. I will shortly orphan the following packages: pidgin libsilc pidgin pidgin-guifications pidgin-libnotify pidgin-rhythmbox No problem, I've already taken over pidgin. Thanks! - -- Jan Synacek Software Engineer, Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTAhOTAAoJEL3BmMJQOtjBhLgP/1khnhoSao3UILZ8QTiekxMM 0JjpOsRnvLOGqT+BTulkUoassbh/iLk3vIxTUQesAU38x2rVyPLCXpol/7oeGeRU CEl6eaFkgrC8mNEVJb/+6T1DHMxmDEDTdICQCurszt7muRjSgfQF6V1I/YFgo0gS x/N53G9j+CWrgawwWxY1ArcQvfRphPDrO46TFTx8CrC5H4rTQ16IMb8Kg3Ll7SRB GV4mIvi/gkbwk4vDtj+EgjbYdA2NI4vMobzpHhnETzwz8V3a4kx05GJ4Xma2+hvF tO9pno6U40YSsG8wgfMe8VpkagNeXbs6fJrU/kJsSU4VBVLV+n8+wfsoBR7H941h Mv6JHWRPcZ1hkPrmqGE6mlYnIt64cYzQHUCW8bK/CVzblyPMQrXopD3TvKD1eA9o OjHOt8gWfQM9VgSF3A0u38LBy3sWUxyo1m9tAGq3IvdIHz93/RmqPavrR5yJ0IIT g8Q/W0DnJSwSrSflvMLO5YW/Op5xHgNcavXMtDsFwERV8QNBOUcu8cEwU8AH5Y2K /RIY/wkvbyVJq1bWBKEnz+uoM8TglNa4O6WqGVTHdKDJCLpTcNNsiVIrbSrYlDLF 7KDQuDOBpxADgmoFQbaQ2UTnPuyEGRbxJZpj3ijzZPZhzc4p9jPx8gFldSWjWfuy +WyWQPfypoqLjyrCScRZ =ou54 -END PGP SIGNATURE- -- 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: Unresponsive maintainer - pidgin package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/12/2014 12:47 AM, Dominik 'Rathann' Mierzejewski wrote: Hi Jan, On Monday, 10 February 2014 at 13:35, Jan Synacek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2014 01:32 PM, Jan Synacek wrote: Hello, I've been trying to contact Stu Tomlinson for a while now -- in a bugzilla [1] and by mail. Anybody know how to contact him? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1058220 Cheers, Adding Stu to CC, which I totally forgot... While you're at it, could you please ensure that the pidgin package in RHEL7 includes Gadu-Gadu support (#1064053) and that the latest libgadu is used (which supports SSL certificate validation)? Regards, Dominik Unfortunately, that's not up to me to decide. I don't maintain pidgin in RHEL7. - -- Jan Synacek Software Engineer, Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/GyFAAoJEL3BmMJQOtjB9OUQAJt/GBFRTDGj/4pMvGeqeOov ecUMjJbIVnF9C1KlNR9svdp9rwnQc1qLsm1y9IxNsESOJxBATxHP4/0QenVWvUnx hvT2yHwIVEdGsCQpthLnf1dSHUvGBcIy/mZYXIMEZi8KSm6cXsn8Az81EqpevQ2x gccdr1vP2dvFW0uc4R2k+6FMTTODIMOU/fzVCFbbmEIEzCixg3nJMgdYHpchwSAP aCJLGd9dtDv8REIoto1K0jmb4/2VPWX9RCfIPHubmXGovhd488HLdGYUHdgkIx4b ihU0gg3N7U8hturFibuO2TjsxyIqY3vguNkpxqwLr+XqN5cImlJcg4yQyM+IfH1Y 9Qf/n+YemonhHBat5GYJoXY2PZUt8iOqCSmRm+DydC0yChdG5IPaiwgK0opc7l81 F8Vom77D5F51xeHoGFa1CrCfzI2hYpnBE8gElsO1SfSguX1BZcrPiJs1i823+iKP ZCo4aqRQ9WMl4H0niMB/mn71bub8aL+9v1qPExEa7pR0thCskQJ5VKsUrZqkykar vP1aSHIYdm0Bw12R2bTz0cM/6xgiBn++e9x7s1atF7TsDQm8nXaxYXALzgjYOSlN OajxDOehMj3L1O2YXXo0f2HEaQTnd/lJG2KlXXgvMfj1MdDxO90MdkUMhCzY0qqR SdbWA3oGbXcaO8yRPJG7 =W3yI -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unresponsive maintainer - pidgin package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I've been trying to contact Stu Tomlinson for a while now -- in a bugzilla [1] and by mail. Anybody know how to contact him? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1058220 Cheers, - -- Jan Synacek Software Engineer, Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+MbAAAoJEL3BmMJQOtjBIk0P/RXPapEk8E8a+JLsP07yH0rt b6Jk5Lf/XZTLDxfx9psAMwWcxb5F30aPQU/R3cux20DMM2noUEUCxxjQ0h/0gfnX yWy99+k4mAmAngPjSa5SgtFJlTcONECKtmn650jtxkYkzTs3ipW7R6e3JOm4KTqR NIMgnbGFgnOgk1LJFjjI5cAdC3NYtZnBslNOmCd24Co/ZNl/Qk+S4C+4Vxe7S16u nqCnEyxuGp9yvRKQRcyfdO334Wh6OjDK+lZkHe1Twg0SQuUaeG0HeOn91kNhPyPj eTAA+ZTdzT5B0LxKtET+NcYmlJV9Dt5DLcGESujqFjTFQ16QOHbHAMWXV4llfoCf upw4Yws7/r73NlRDpFBTgwSzyLgIHnCOWwgNGlxsZSK2x3SQkqt29w2juM66/6n7 hXLf9cBQYpe4hwulXZlzuyoZdzO7mJowr13FoeS2gnsXJmDjA6KYxvhTE/vX1URw QA8JVZm5TZ3FaTzEMTdMPUBoDjkfWlMnwNjKAgApCGxDdUvHxyhspIAhd/lR2kBU ZZ2nu/cwlyDd42AkJVqPaqMxJV2ALE0M/i455wmICCVStvwQV53cG9g0E/dX+ZEb B53e/Wep6cOVsnXqF6T8s3yBEGKV0niKdhZlnpS7OW2BbaiFldBuBIgt4V0CZEBo 1LkeJG/KC5iE5wKbovcv =T6fk -END PGP SIGNATURE- -- 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: Unresponsive maintainer - pidgin package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2014 01:32 PM, Jan Synacek wrote: Hello, I've been trying to contact Stu Tomlinson for a while now -- in a bugzilla [1] and by mail. Anybody know how to contact him? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1058220 Cheers, Adding Stu to CC, which I totally forgot... - -- Jan Synacek Software Engineer, Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+Md+AAoJEL3BmMJQOtjBcYgP/0RLdQ1v7aQNaC7ytM/fKtxH kCS5w0duK4CFOAfyEdrlOPBZdnM3/9utXuievGwXA3Y2jpr/GJ/ItuQRL907kl13 yCneFf86ERplIbeUWb+D0z4oZHEZjnUObssS3m+nPCjVm1pwR2Vk7Ty0eCSgmYeR 9Zrj1C+8KFbZY3sNdnNDpqFK2Txp5SEj0nH1P9YoDeppzquKU6ynUtW6s1+P7BgD Hdd6+uWp3VP39d1YKFuAhp4Y8RdlIV9fCc3FCXCgX/OxDjhCZDFr+cl2YDgZj+8J V0mGCyQTVAUFcWgELILBSIu1yCFM6YlZkQ9jYDMp9SzcLCKB93KtAX23TwbTqe4Z XXOybJhT02OoJvgC3q1119QnTmFzjztkr05ySuvVoiah9QFYsMHvDffRW6za9Bs/ IziSegLQ0mUORTaPQYtZR/CUAqytOZkSAf4J+RpAKwlmQseEhV3H9mfFiO9xwHWt XUzUqvs/fDu5Ei5TOaBt6EWlvo14ABtZqA69laG73iRu82piU9O9DlZHIzFM3AcY mJIk6SVxqZWmoFRkIT80BFvvMME85n8xfVruBlZJa6Xe87N9oyBH69qoLexRjOBK /Zd0S4yzqAWpWXZzsfvBR3+3RC3bZLJER360leO4yDHquyH2F6EsaQa9aBDYErhv oibNuCklzjB01f/4bict =9JcM -END PGP SIGNATURE- -- 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: Source file audit - 2013-11-17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/14/2014 10:03 AM, Jan Synacek wrote: On 11/18/2013 04:54 PM, Kevin Fenzi wrote: jsynacek:BADURL:xferstats-2.16.tar.gz:xferstats xferstats.off.net seems to be down. I'll try to contact the author who is mentioned in the manpage. In case I get no response, should I just remove the URL? I couldn't find any other upstream sources. I contacted the author and he told me that there was no upstream source anymore. I'm going to retire the package in 7 days. If somebody feels a strong urge to maintain it, let me know. - -- Jan Synacek Software Engineer, Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS3RXIAAoJEL3BmMJQOtjBHP4QAJKb8M3ndnDfbNQai2UrJinj y/fE/IliaDd4F6773M96KJpHFUjp90s3AXunEGv1AxHFGTb2so0dRGquTBehLpxq 059lRxN6N3eQqih+YmRhVIaWSEWeiIS5VHKXwieGZRRU4XRGa5UhaMDfQrtd8//Y 0K31vERhNErje2xbdBNR1HHDc8yMgfqcxVIgTWjvrENC+M8nd65OlHSu/Ih6Fw4H V/dwo3ALaWoTLUe+QNPqP5AfuSCMwTbH8WVa+rW8faQCfic9bPlxBxSXZS+q0MzL gr0ARgpA88yVng/EYohz3pZgCUUMd7rpqg1i1IduNhOAMxhFKUN620KPGrLNIv6h VRC0rfYmyg1Nu1k6Kw8rA5pafFVXjQrUtRDERbnme+x0dHVR3ZG/mQ+kZkMLPkXT XMxafRNAm2+1EbWRlxq603klOPoUu4u3Vb94FsVTnE2v1ezcJKc95/ZFnRzx/dQ8 1gsAxq2uJfQHCDckbmlNUrJCH3nAdDPSZBwIA9FeReraBG8A1/UpQYuDZYVfr5YY W+IzASDpFG+Nfti330yWnexUwrTJa6Bbnx3KBC0m+W4j34GBvycYgVXvrWmEQi0M yWUUcdaonxI+3o3X9TmJCox6XK8o2DC0At7jK1Is2cKTToycN7iqOiuvpJBleCc+ bm/JBUP/i64Xm4xzXuPd =0xBS -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
pidgin maintenance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, there are a lot of pidgin bugs (mainly crashes reported via abrt) that have been piling up in the bugzilla for quite some time now and nobody is taking a look at them. Although I am a co-maintainer, I can't devote much time to pidgin. I spoke to Milan Crha, the other co-maintainer, and neither can he. I tried to contact the owner of the package (CC'd) in November, but got no response. I think that pidgin deserves more care than it currently gets. Having said that, I'm about to start non-reponsive maintainer process, however I do not want to be the owner of the package. Is anybody willing grab pidgin? - -- Jan Synacek Software Engineer, Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS1O9YAAoJEL3BmMJQOtjBLXIP/ihrbTC+d0R0b2moI+ovz5Dc R4S1KwiY+ApaoRRraXiLlkJOkZyio1MHzxpsN1JPKubNqka7U3hjJFcwFk8o8q95 cbY87ADwZoH+vAt4F7RzxM8mmKvWeSnk7I0Rzx6zB4kbXdfUvaRAV1xt3EO3SZhZ RL7k+Rk+5g+qOsEjPFW9P36XqqKfFHHmcKMgx7SuJezAAzC1bvXrA9hryVYQrXzg AVJDUyTKlO5ohMk3iVkrHhK0waWgqlOZ2+xaZrp1mNLVbHKrHZ8q1i/cirP/cKzz VrYuK9XuNleX+Y9FpRVwzuxvCVYmV1xTN5SOHmtEhsOVQjbzEJH25vORCpt2vI6E IhYRZNIrj9vOgaCOh3iYZ9+LT11WmabWNaefwHypLtbdCauv7/WZoD8yv+mok0l2 D34y8PImA1hW6a0Ki5y1D5Hmm+UjX5XwNJhr6jDqnQTy3m4euHf52Qmu7B23zQ7a GS4k//CjUQUxgW+AdDa06a7y7cjR3OJVg3TIkEym92TOTa55ETVpuzalN8QrSq7L 1ryzxrpGip6jUiTi85hWgG4H7a+/9jf74sOOVP29Tt4xzcb9W2UWqzwHbvZtYAwv goULUkELda5vFE9OFyBJh46XKb4T3pi18DFp9T8Go55JG/tRKgXHisXjiV577n+F JWsNtLf5s/H26uLxe0gf =9aJx -END PGP SIGNATURE- -- 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: Source file audit - 2013-11-17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2013 04:54 PM, Kevin Fenzi wrote: jsynacek:BADURL:xferstats-2.16.tar.gz:xferstats xferstats.off.net seems to be down. I'll try to contact the author who is mentioned in the manpage. In case I get no response, should I just remove the URL? I couldn't find any other upstream sources. jsynacek:BADURL:xinetd-2.3.15.tar.gz:xinetd Fixed. - -- Jan Synacek Software Engineer, Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS1P1wAAoJEL3BmMJQOtjB5EoP/0FVE49SBnE/WsLjyw6f7+UN O1bnkM0hOvbItWtUmX5URyAqIfsUZ0gBzodIMWT3sHYrE2wshMKObo4UA5zEToMO SmMpYsTYS7hDu6iLZO1OaN7cXIu1V9ic5y0PHvYRG5PQc6q71ofcDO3qZoJmeb7L +DLCVLw2flVYnC5ANRU2cC+Qi0L31Tu/5W6K3MQfhZu6BvLWdMS1iHrDhNj4Tiys 67F6PJ8JeZH/L3IBZZb6OYBvDiQgnMrfB5HIauo84V3Cr03GIEgrAy4JMeo++c9M qSq9XKAxq3WUU6krRk3+itnfILxa3SDKQbNklvD8czvQ7RU92jQUgz1azZet69Mn 8VSv+J+i5ts0SB1l7ZmK9gCSNkQp6Ii2Z/qdKbGQ4xpibm+/DTw2YZDZZBTyBKvf raCgxpBARDxmdFJdBThODLAQuqO+Ol5sVnHT361KqoCWU1wvFPLoZaRIKatlSS99 i9HlKR3phBY5xTrnfPO12zCuRa+RJZ+w/1Rxq8Gxq9kmokQqa1GBXHRAQARzvRrs 4FdNdv2221JioQiLOfzGV/eIkzmtUPgkj83kEiOnVoclpaGxPUHvB0JRehKGLzOU NKhMlTRe42h+8Ks2g2+ccJGLC+FaymTS6LHWQWXnpkn7uIK4yGpTp0BKISh/NRU9 /k/Pj/9dRlJMfomhowr7 =cDDp -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Rawhide grub messed up
Hi, I just updated my rawhide machine and it stopped booting. I end up in grub rescue prompt, stating that there is no '/grub2/i386-pc/normal.mod'. grub rescue ls /grub2 ./ ../ themes/ grub.cfg grub rescue set prefix=(hd0,msdos1)/grub2 root=hd0,msdos1 Partition seems to be right, why msdos escapes me, though. How do I fix this mess? Cheers, -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rawhide grub messed up
On 08/21/2013 01:41 PM, Jan Synacek wrote: Hi, I just updated my rawhide machine and it stopped booting. I end up in grub rescue prompt, stating that there is no '/grub2/i386-pc/normal.mod'. grub rescue ls /grub2 ./ ../ themes/ grub.cfg grub rescue set prefix=(hd0,msdos1)/grub2 root=hd0,msdos1 Partition seems to be right, why msdos escapes me, though. How do I fix this mess? In case somebody runs into the same problem, I managed to fix it. Mount and chroot to the root filesystem from a live cd and reinstall grub2 with 'grub2-install my-disk'. Simple yum reinstallation did nothing (there still was almost empty /boot/grub2 as shown in the original message). I'm not sure why there was nothing but themes and a config file in /boot/grub2 after the installation/reinstallation. I tried grub2-2.00-21.fc20.x86_64.rpm, grub2-2.00-23.fc20.x86_64.rpm and grub2-2.00-24.fc20.x86_64.rpm, all resulted in the same broken /boot/grub2. Anybody have any clue? Am I the only one that ran into this? Or is it broken? -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: No Default Syslog
On 07/15/2013 11:22 AM, Frank Murphy wrote: On Mon, 15 Jul 2013 10:44:44 +0200 Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: No Default Syslog = https://fedoraproject.org/wiki/Changes/NoDefaultSyslog Change owner(s): Lennart Poettering lennart at poettering net, Matthew Miller mattdm at fedoraproject org No longer install a traditional syslog service by default. (Specifically, remove rsyslog from the @core or @standard groups in comps.) The systemd journal will be the default logging solution. Rsyslog, Syslog-NG, and even traditional sysklogd will continue to cover use cases outside of the default. Can systemd journal be picked up by logwatch?, or similarly be emailed on a daily basis, without user creating a bagful of scripts? No, logwatch works only with traditional text-based logs. There is this RFE filed [1], but that will probably not happen as it would require a total rewrite. It would make more sense to write a new logwatch-like utility from scratch, that handles only the journal. It's somewhere on my todo list, but has quite a low priority:( [1] https://bugzilla.redhat.com/show_bug.cgi?id=864872 -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: su starts behaving oddly sometimes on F19
On 05/17/2013 07:29 AM, Adam Williamson wrote: This is a weird bug I've seen 3 or 4 times since upgrading to F19, and am having trouble pinning down. Occasionally, after my session has been up for some time, runs of 'su' start behaving oddly. After I enter the root password, it takes a long time - longer than the delay that's always happened when you fat-finger your password, even - before it succeeds. Usually, of course, it's instant. But when this bug happens, I just get to sit there while it thinks about it for like 10-15 seconds before I eventually get a root prompt. This only applies to my desktop session - but it applies to any terminal running in the desktop. At least, it applies to gnome-terminal (even if closed and opened again) and xterm. But if I go to ctrl-alt-f2, login, and run an 'su', that still returns instantly. I've tried strace'ing su, but interestingly, I can't get it to work: running su via strace always seems to result in Authentication failure (which doesn't display this bug; it's only _normally_ slow, the same slowness that has always been the case when you fail the password). So I'm kinda stuck, really. Has anyone else seen this? Any bright ideas for debugging it? Thanks! Just a guess, but is your shell a subprocess of sssd? I have no idea if that might have any influence. But, I noticed, that on my machine, all of my bash processes are spawned via sssd, even though I didn't configure or even enable it. If that or anything similar happened in your case, I wouldn't be surprised that your shell is waiting for some timeouts while doing authentication that you might not know about. Again, that's just a wild guess. -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange ssh / openldap linking problem
On 04/22/2013 12:22 PM, Richard W.M. Jones wrote: On Mon, Apr 22, 2013 at 11:27:42AM +0200, Michael Schwendt wrote: 3) Funny things going on (f19 here), but haven't examined anything beyond this: # rpm -e openldap-devel # ldconfig -v|grep ldap libldap_r-2.4.so.2 - libldap_r-2.4.so.2.9.1 libldap-2.4.so.2 - libldap-2.4.so.2.9.1 # yum -y install openldap-devel # ldconfig -v|grep ldap libldap_r-2.4.so.2 - libldap_r.so libldap-2.4.so.2 - libldap.so That makes no sense. Indeed. That looks like there's something wrong with ldconfig. On my (now fixed) system I get the same output from ldconfig: $ sudo ldconfig -v | grep ldap ldconfig: Can't stat /libx32: No such file or directory ldconfig: Path `/usr/lib' given more than once ldconfig: Path `/usr/lib64' given more than once ldconfig: Can't stat /usr/libx32: No such file or directory libsmbldap.so.0 - libsmbldap.so.0 libldap_r-2.4.so.2 - libldap_r.so libldap-2.4.so.2 - libldap.so which as you say makes no sense. On the other hand, the links on the filesystem are still correct: $ ll /usr/lib64/libldap-2.4.so.2 lrwxrwxrwx. 1 root root 20 Apr 22 09:26 /usr/lib64/libldap-2.4.so.2 - libldap-2.4.so.2.9.0 Rich. Have you found out how this originally happened? I can't get any of my f18-f20 machines to this state. -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange ssh / openldap linking problem
On 04/22/2013 12:22 PM, Richard W.M. Jones wrote: On Mon, Apr 22, 2013 at 11:27:42AM +0200, Michael Schwendt wrote: 3) Funny things going on (f19 here), but haven't examined anything beyond this: # rpm -e openldap-devel # ldconfig -v|grep ldap libldap_r-2.4.so.2 - libldap_r-2.4.so.2.9.1 libldap-2.4.so.2 - libldap-2.4.so.2.9.1 # yum -y install openldap-devel # ldconfig -v|grep ldap libldap_r-2.4.so.2 - libldap_r.so libldap-2.4.so.2 - libldap.so That makes no sense. This bugzilla looks like it explains that behavior. https://bugzilla.redhat.com/show_bug.cgi?id=159601 -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Guile2
On 01/23/2013 04:54 PM, Kevin Fenzi wrote: On Wed, 23 Jan 2013 09:58:09 -0500 (EST) Jaroslav Reznik jrez...@redhat.com wrote: = Features/Guile2 = https://fedoraproject.org/wiki/Features/Guile2 Feature owner(s): Jan Synacek jsyna...@redhat.com Update GNU Guile to version 2.0.x in Fedora 19. == Detailed description == Current guile package will be upgraded to 2.0.x. compat-guile18 package will provide additional time for the packages to be ported to guile-2.0.x. Passing along for someone who's not on list: This is a major new revision. It has had some startup problems. Please do not use any version earlier than what is, right now, the absolute latest version. The current stable release is 2.0.7. Thank you. because my application has stumbled fairly hard over issues that were not fully addressed until this particular release. If that is the version already planned, then that is all I really need to know :) So, is 2.0.7 or later planned? Yes, currently, the latest version (2.0.7) is prepared. If there's any new release by the time I will be updating it, I'll use the latest one. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Guile2
On 01/23/2013 10:23 PM, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Features/Guile2 = https://fedoraproject.org/wiki/Features/Guile2 Feature owner(s): Jan Synacek jsyna...@redhat.com Update GNU Guile to version 2.0.x in Fedora 19. == Detailed description == Current guile package will be upgraded to 2.0.x. compat-guile18 package will provide additional time for the packages to be ported to guile-2.0.x. Will compat-guile1.8 provide guile = 1.8 (and similarly for compat-guile1.8-devel? Yes. The compat package has already been built for rawhide. It's also been tested pretty well during the review. https://bugzilla.redhat.com/show_bug.cgi?id=868263 -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
iputils: Recent rawhide changes
Hello everybody, there's recently been quite a lot development going on upstream. I'm trying to keep up, fixing bugs as they come and updating/dropping patches. I would like to encourage those of you using rawhide to be suspicious of anything that you find (if only slightly) weird in iputils and to file bugs without mercy;) Cheers, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package
On 10/23/2012 12:52 PM, Kalev Lember wrote:
On 10/23/2012 12:12 PM, Jan Synacek wrote:
This is what I had originally in mind. After trying to realize this idea and
consulting it with the maintainer (I'm a comaintainer of guile), it didn't
seem
right. The problem is that a lot of things have to be renamed, including some
autotools macros, and that creates a lot of mess long term (if it was done
the
the new package). With the compat package however, this are renamed as well,
but
it's the old stuff and then you can only slightly patch (mainly spec, no code
changes needed) the old apps so they compile and run and don't have to worry
about future changes. After guile is upgraded to 2.0.x, you can slowly start
porting as well.
Huh, I hope my point is clearly visible in my slightly complicated message..
Oh, I see -- are you trying to make guile 2.x and guile 1.8.x -devel
packages parallel installable?
I am not sure it's worth the effort. Or more bluntly, I am not even sure
it's the right thing to do. E.g. something like the following (from
compat-guile1.8 spec file) strikes me as unusual and can cause a lot of
churn in dependent packages:
ac=${RPM_BUILD_ROOT}%{_datadir}/aclocal/guile1.8.m4
sed -i -e 's|,guile|,guile1.8|g' $ac
sed -i -e 's|guile-tools|guile1.8-tools|g' $ac
sed -i -e 's|guile-config|guile1.8-config|g' $ac
sed -i -e 's|GUILE_PROGS|GUILE1_8_PROGS|g' $ac
sed -i -e 's|GUILE_FLAGS|GUILE1_8_FLAGS|g' $ac
sed -i -e 's|GUILE_SITE_DIR|GUILE1_8_SITE_DIR|g' $ac
sed -i -e 's|GUILE_CHECK|GUILE1_8_CHECK|g' $ac
sed -i -e 's|GUILE_MODULE_CHECK|GUILE1_8_MODULE_CHECK|g' $ac
sed -i -e 's|GUILE_MODULE_AVAILABLE|GUILE1_8_MODULE_AVAILABLE|g' $ac
sed -i -e 's|GUILE_MODULE_REQUIRED|GUILE1_8_MODULE_REQUIRED|g' $ac
sed -i -e 's|GUILE_MODULE_EXPORTS|GUILE1_8_MODULE_EXPORTS|g' $ac
sed -i -e 's|GUILE_MODULE_REQUIRED_EXPORT|GUILE1_8_MODULE_REQUIRED_EXPORT|g'
$ac
The two -devel packages could just as well have explicit Conflicts set
to make sure they can't be installed at the same time; I don't think
it's important to hack them up to make them parallel installable, if it
involves such invasive changes.
What really matters is that end users can have 1.8 and 2.0 interpreter
and libraries installed at the same time. Not -devel packages; these are
mostly just used within koji for building binary packages.
This also appears to be what Debian is doing.
Parallel installable guile interpreters:
http://packages.debian.org/sid/amd64/guile-1.8/filelist
http://packages.debian.org/sid/amd64/guile-2.0/filelist
Conflicting -dev package:
http://packages.debian.org/sid/amd64/guile-1.8-dev/filelist
http://packages.debian.org/sid/amd64/guile-2.0-dev/filelist
What you describe here is my original proposal:)
Yes, both packages are parallel installable now. And the effort isn't that great
really. Whether it is the right thing to do, I don't think the answer is clear
as well (see Toshio's and Adam's answers down the thread). And further, I think
that such changes are not invasive at all, as they affect only the old versions
of stuff.
Guile2 package would require some scripts and the binary to be renamed and then
symlinks would have to be created, which would cause more mess IMO. Creating a
compat package and then updating guile simply seems more natural to me. As far
as the patches for the dependent packages are concerned, I'd probably be able to
patch all of them myself, as the patches are really quite simple (a lot of
mechanic work though).
Anyway, I think that neither of those solutions is far superior in any way.
Maybe I could drop all the renaming in the compat package and make it conflict
with guile-devel, but that there seems to be no agreement on whether it is or is
not a good solution.
So, if nobody really objects, I'm going keep the current solution.
Cheers,
--
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package
Hello all, I've created a review request for compat-guile1.8: https://bugzilla.redhat.com/show_bug.cgi?id=868263 Once the compat package lands in rawhide, I will leave some time for the transition (I may work on the required patches if time allows me). After that, guile (now version 1.8) will become 2.0.x. I've already tried patching a few packages and there seem to be no real problems, unlike patching the old apps for the new guile. Affected packages: aisleriot autogen coot denemo drgeo freehoo freetalk geda gnubik gnucash gnurobots gnutls graphviz libctl libgeda lilypond mdk rumor TeXmacs trackballs xbindkeys Cheers, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package
On 10/23/2012 11:15 AM, Kalev Lember wrote: On 10/23/2012 08:51 AM, Jan Synacek wrote: Hello all, I've created a review request for compat-guile1.8: https://bugzilla.redhat.com/show_bug.cgi?id=868263 Once the compat package lands in rawhide, I will leave some time for the transition (I may work on the required patches if time allows me). After that, guile (now version 1.8) will become 2.0.x. Hello Jan, Very cool. The lack of guile 2.0 has been keeping Aisleriot updates back for several Fedora releases now. Are you planning to make the 2.0 version available for F18 as well? I'm quite hesitant to update F18 as well. I mean, it would be nice, but I'm not sure if all can be probably patched and tested in time. If only I had done this a few weeks earlier..:) -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package
On 10/23/2012 11:55 AM, Kalev Lember wrote: I agree, updating 21 packages is a bit too much at this point in F18 schedule. However, a way to make this work for F18 would be creating a parallel installable guile20 package. So instead of what you are planning now: guile-2.0.x compat-guile1.8-1.8.x We'd have: guile20-2.0.x guile-1.8.x This way no apps need to be updated for the guile - compat-guile1.8 transition. Instead, they could be ported to guile20 at their own pace and there wouldn't have to be a flag day for switching all of them over at once. This is what I had originally in mind. After trying to realize this idea and consulting it with the maintainer (I'm a comaintainer of guile), it didn't seem right. The problem is that a lot of things have to be renamed, including some autotools macros, and that creates a lot of mess long term (if it was done the the new package). With the compat package however, this are renamed as well, but it's the old stuff and then you can only slightly patch (mainly spec, no code changes needed) the old apps so they compile and run and don't have to worry about future changes. After guile is upgraded to 2.0.x, you can slowly start porting as well. Huh, I hope my point is clearly visible in my slightly complicated message.. Cheers, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New guile2 package
Hello all, since porting apps to guile2 has been pretty painful so far, I decided to take another try. My take so far has been to create a new package called guile2. This will allow for the new packages that depend on guile2 to be built, while the old stuff won't be broken because guile1.8 will still be around. What would be the preffered way to proceed? I think the best way is to leave one version (likely guile2?) as the default and rename the binaries and some other conflicting files in the old package. I can also rename the original guile to something like guile1.8 and update the original content with guile2 stuff, but IMO that is pretty cumbersome. Some problems I've encountered: * Multiple info files. I suggest keeping only those in the new package and remove them from the old one. * Both packages contain guile.m4. This is the only problem I'm not sure how to solve yet. Both packages also contain guile-config that can be called by one of the autotools macros. I guess that renaming that file in both packages and symlinking it from the default package would be ok in theory, but that still doesn't solve the problem with the m4 files. Any thoughts? Anyway, you can find the packages here [1]. They should be installable and runnable in parallel with guile. These are not meant to be final in any way, just to demonstrate that it would be quite possible to have both of them in the system. Thoughts and feedback appreciated. [1] http://jsynacek.fedorapeople.org/guile/pkgs/ Cheers, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120925 changes
On 09/25/2012 02:58 PM, Fedora Rawhide Report wrote:
Compose started at Tue Sep 25 08:15:11 UTC 2012
Broken deps for x86_64
--
...
[gr-air-modes]
gr-air-modes-0-0.3.20120905git6c7a7370.fc19.i686 requires
/usr/sbin/ldconfig
gr-air-modes-0-0.3.20120905git6c7a7370.fc19.i686 requires
/usr/sbin/ldconfig
gr-air-modes-0-0.3.20120905git6c7a7370.fc19.x86_64 requires
/usr/sbin/ldconfig
gr-air-modes-0-0.3.20120905git6c7a7370.fc19.x86_64 requires
/usr/sbin/ldconfig
...
This looks like a bug to me. The package requires %{_sbindir}/ldconfig, which is
fine AFAIK.
--
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: guile-2.x: what is the way forward
On 08/28/2012 08:17 PM, Debarshi Ray wrote: The update to guile-2.x has been blocked for almost 1.5 years now: https://bugzilla.redhat.com/show_bug.cgi?id=678238 Long story short, existing programs are not ready to use guile-2.x, while newer versions of aiselriot (part of GNOME) need it. Creating a compat-guile or a guile2 package can be one way forward. What do you think? Would be good to get this resolved finally. Thanks, Debarshi I've been trying to patch some of the apps to compile with guile-2.x some time ago. Some of them compile, some of them even run.. With my limited knowledge of the guile API, I haven't finished all of them though. The good thing is that the upstream is very active and very willing to help. I think that installing both versions in parallel (if possible) is a good way to go, but then the old programs won't ever get patched:) IMO the best way would be some kind of a compatibility layer in guile itself, but I don't think that's worth the trouble and the net gain for the upstream. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package with no upstream (ftp)
On 07/19/2012 09:42 AM, Paul Black wrote: On 19 July 2012 06:15, Jan Synacek mailto:jsyna...@redhat.comwrote: On 07/18/2012 04:15 PM, Bill Nottingham wrote: Did the netkit upstream finally give up the ghost entirely? If so, it likely affects more packages than just ftp. Bill [1] seems to be dead. And I haven't found any other places with the source, apart from some Slackware mirrors. What other packages can be affected? [1] ftp://ftp.uk.linux.org/pub/linux/Networking/netkit Does ftp://ftp.linux.org.uk/pub/linux/Networking/netkit have what you want? -- Paul AHA! Yes, it does. Hmm, I wonder where the mangled url I used came from. It's been written like that in the spec since forever.. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package with no upstream (ftp)
Hello all, what should I do with the spec file of a package (ftp) with no upstream and no upstream source? I mean the URL and Source0 lines. Should I just let them there, put a note in a comment or just remove them? I haven't found anything about such case in the guidelines. Thanks, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package with no upstream (ftp)
On 07/18/2012 10:43 AM, Colin Walters wrote: On Wed, 2012-07-18 at 10:19 +0200, Jan Synacek wrote: Hello all, what should I do with the spec file of a package (ftp) with no upstream and no upstream source? I mean the URL and Source0 lines. Should I just let them there, put a note in a comment or just remove them? Upload it to fedorahosted, gitorious, github, or whatever. Even if you're the only person with access initially, it's still useful as a possible code sharing mechanism with other distributions, etc. And who knows, maybe someone will come along and submit patches. Sounds reasonable. Thank you. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package with no upstream (ftp)
On 07/18/2012 04:15 PM, Bill Nottingham wrote: Did the netkit upstream finally give up the ghost entirely? If so, it likely affects more packages than just ftp. Bill [1] seems to be dead. And I haven't found any other places with the source, apart from some Slackware mirrors. What other packages can be affected? [1] ftp://ftp.uk.linux.org/pub/linux/Networking/netkit -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pidgin 2.10.4
On 07/10/2012 03:46 AM, Stu Tomlinson wrote: snip Just about. co-maintainers welcome. Regards, Stu. I will be happy to help. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/03/12 at 01:34pm, Tomasz Torcz wrote: On Sun, Jun 03, 2012 at 01:21:55PM +0200, Andrea Musuruane wrote: On Sat, Jun 2, 2012 at 8:17 PM, Andrea Musuruane musur...@gmail.com wrote: On Tue, May 29, 2012 at 10:42 PM, Neal Becker ndbeck...@gmail.com wrote: Basically the same kind of failure as the last several times I did updates. This time f16-f17. Used preupgrade. I'd like to share with you my experience about installing Fedora 17/x86_64. It is a real PITA. No doubts about it. 6th attempt: I did a minimal install also enabling remote updates and at last I can boot Fedora 17. Now the problem is how to install a graphical desktop environment from minimal install. I googled without finding nothing really useful. As previously, any help is really appreciated. yum groupinstall GNOME Desktop Environment This alone unfortunately doesn't do the trick. You will probably have to yum groupinstall X Window System as well as some drivers for your graphic card to get it working. I also had to order selinux to relabel my entire /home to be able to get into any gnome session. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Autoreconf race condition?
Hello all!
I've run into a problem when I was trying to build tftp (master branch) package
locally.
~/work/tftp$ fedpkg local
...
config.status: creating MCONFIG
config.status: creating aconfig.h
configure: WARNING: unrecognized options: --disable-dependency-tracking
+ make -j4
rm -f aconfig.h.in aconfig.h
echo \#define VERSION \tftp-hpa `cat version`\ version.h
autoheader
make -C lib
make -C common
make[1]: Entering directory `/home/jsynacek/work/tftp/tftp-hpa-5.2/common'
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -W -Wall -Wpointer-arith
-Wbad-function-cast -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -Winline -Wwrite-strings -Wundef
-Wshadow -Wsign-compare -pipe -fno-strict-aliasing
-I/home/jsynacek/work/tftp/tftp-hpa-5.2 -c tftpsubs.c
make[1]: Entering directory `/home/jsynacek/work/tftp/tftp-hpa-5.2/lib'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jsynacek/work/tftp/tftp-hpa-5.2/lib'
In file included from tftpsubs.h:41:0,
from tftpsubs.c:34:
/home/jsynacek/work/tftp/tftp-hpa-5.2/config.h:21:73: fatal error:
aconfig.h: No
such file or directory
compilation terminated.
Notice the execution of rm -f aconfig.h *after* make. The spec doesn't seem to
be wrong:
...
autoreconf
%configure
make %{?_smp_mflags}
...
And here is the corresponding part from the build log:
...
autoreconf
CFLAGS=${CFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=gen
CXXFLAGS=${CXXFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune
FFLAGS=${FFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=gen
LDFLAGS=${LDFLAGS:--Wl,-z,relro }; export LDFLAGS;
./configure --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu \
--program-prefix= \
--disable-dependency-tracking \
--prefix=/usr \
--exec-prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--sysconfdir=/etc \
--datadir=/usr/share \
--includedir=/usr/include \
--libdir=/usr/lib64 \
--libexecdir=/usr/libexec \
--localstatedir=/var \
--sharedstatedir=/var/lib \
--mandir=/usr/share/man \
--infodir=/usr/share/info
make -j4
...
I also noticed a rather weird comment in the Makefile:
# Adding configure to the dependencies serializes this with running
# autoconf, because there are apparently race conditions between
# autoconf and autoheader.
aconfig.h.in: configure.in configure aclocal.m4
rm -f aconfig.h.in aconfig.h
autoheader
This part also seems to be causing my problem. Adding configure to the
dependencies apparently does not help.
I don't really know what the root cause of my problem is. I looks like a race
condition between some of the autotools, but I'm not really sure.
The problem goes away when I add sleep 1 between autoreconf and %configure in
the spec file.
Any ideas?
Thanks,
--
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Logwatch - looking for testers
On 05/05/12 at 08:46pm, Richard Vickery wrote: - Selinux Audit Begin **Unmatched Entries** snip Thank you, Richard! -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Logwatch - looking for testers
Hello list, I'm looking for as many logwatch runs in Fedora 16 as possible. I need to test the F17 package so I know if there are any problems with compatibility. Please, consider installing the new build [1], running it, sending me a logwatch report and possibly sending logs (obfuscated if need be) if there are any unmatched entries. You can run logwatch like so: logwatch --range all --service all [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=317339 Thank you! -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Logwatch - looking for testers
On 05/04/12 at 09:38am, Frank Murphy wrote: On 04/05/12 09:35, Jan Synacek wrote: Hello list, I'm looking for as many logwatch runs in Fedora 16 as possible. I need to test the F17 package so I know if there are any problems with compatibility. Typo?, or you want to run the F17 pkg in F16? It's a noarch package and I want to update in F16 with the one that's currently in F17. It should be compatible and shouldn't break, but I wanted to check anyway. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Logwatch - looking for testers
On 05/04/12 at 01:01pm, Frank Murphy wrote: On 04/05/12 12:54, Reindl Harald wrote: Am 04.05.2012 13:48, schrieb Frank Murphy: On 04/05/12 09:35, Jan Synacek wrote: should last 24hrs http://fpaste.org/yH9I/ http://fpaste.org/aOLp/ http://fpaste.org/Lpbn/ http://fpaste.org/c9FR/ you noticed your Date Range Processed: all? ___ And? to quote: You can run logwatch like so: logwatch --range all --service all Range all is perfectly fine - it processes all the logs, not just the ones from one day. Thank you! -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fan switch on permanently
On 03/24/12 at 01:42pm, Antonio Trande wrote: Hello. With my Acer Aspire 6930G happen that after an indefinite time, the fan starts to work permanently regardless of temperature. In this moment, according to nvclock [1] the GPU temp is 43°C and the fan is on; strangely because it starts to work over 47°C all along. If i format the BIOS, the fan goes back to work only over 47°C. Infos: [2] I don't know if this issue depends on Fedora, but i wish understand its cause. Had someone a similar experience o an idea of what is it ? Are you by any chance using nvidia binary drivers? I have a similarly sounding problem on my home laptop using nvidia 8400m and binary drivers. It's described here [1]. While it may not be exactly your problem, maybe it can provide some pointers/hints. [1] http://www.nvnews.net/vbulletin/showthread.php?s=9f6f6c4f2dcd351cecc8a7e890126229t=148976 Regards, -- Jan Synacek BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about commiting the sources
On 03/16/12 at 11:16am, Sergio Belkin wrote: Perhaps and stupid question: After upload new-sources to repo, it outputs: Uploaded and added to .gitignore: Source upload succeeded. Don't forget to commit the sources file I don't understand! By default it add sources files to .gitignore and then it asks for commit them? Is it something that I misunderstood? It just tells you not to forget to commit the file named 'sources'. The file changes when you execute new-sources and should be commited, because it contains an md5sum of the source tarball. The message is somewhat misleading, because the 'sources' file gets staged automatically after new-sources, so if you do fedpkg commit, it gets commited anyway. Hope this explanation is not even more confusing:) Best regards, -- Jan Synacek BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
