Re: Removal of quagga from Fedora
On 10/12/21 4:13 PM, Neal Gompa wrote: > On Tue, Oct 12, 2021 at 7:54 AM Michal Ruprich wrote: >> Hi, >> >> I am planning to start a retirement process for quagga in Fedora. The >> package is very outdated since the upstream is dead for a couple of >> years. There is a replacement in the form of FRR that can be used in a >> very similar fashion and it has active upstream with a lot of >> development going on. >> >> This is more of an FYI message to let you know and to see if anyone >> would miss quagga. >> > Only tears shed for the funny name. Alas, FRR is just too boring! FRR still has zebra at least :D -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Removal of quagga from Fedora
Hi, I am planning to start a retirement process for quagga in Fedora. The package is very outdated since the upstream is dead for a couple of years. There is a replacement in the form of FRR that can be used in a very similar fashion and it has active upstream with a lot of development going on. This is more of an FYI message to let you know and to see if anyone would miss quagga. Cheers, -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Sponsorship for non-maintainers
Hi all, I am facing a bit of a pickle and I would like to discuss this out in the open here. Please keep and open mind while reading. There has been an effort to open-source some of our tests that we have in Red Hat and we decided to place them in the tests/* namespace in Fedora dist-git[1]. Now, our team has some 10 maintainers and we own almost 200 packages in RHEL8(way more than that in Fedora). For all these packages we have only three people in the QE team to test them. So here is the problem: Let us assume, that we create a repository for each component in the tests/* namespace. Now we need to assign access to QE member to these repositories. It would make sense to create a group that would include our package maintainers as well as our QE colleagues. This would help a lot when it comes to stuff changes for instance. As discussed here[2], the only problem here is "once a group is created, it can be given commit access to all projects in the tests/ namespace, but also to any project in the rpms/ namespace or the modules/ namespace and everyone who is committing to these namespaces must be in the packager groups. Thus the requirement for pkgdb group to require the packager membership." But our colleagues from QE don't have sponsorship and therefore are not in the packager group. There are those in RH who said that they would give them sponsorship for these purposes if it is required but I am not sure if that is the right way to do this and I would like to discuss it here. Any input on this is appreciated. Thanks and regards, Michal -- [1] https://src.fedoraproject.org/projects/tests/* [2] https://pagure.io/fedora-infrastructure/issue/9490 -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ 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: Moving tcpdump from /usr/sbin to /usr/bin
Good point, thx Zbyszek. On 8/24/20 4:02 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Aug 24, 2020 at 02:54:29PM +0200, Michal Ruprich wrote: >> Hi, >> >> after a discussion with upstream, I will be moving tcpdump binary from >> /usr/sbin to /usr/bin, similar to how wireshark does this. If you can >> think of any reason why not to do this, please let me know. > Please provide a compat symlink to ../bin/tcpdump though. People > occasionally use the full path to various utilities (in scripts, or > in systemd units, in makefiles, etc.) > > Zbyszek > ___ > 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 -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ 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
Moving tcpdump from /usr/sbin to /usr/bin
Hi, after a discussion with upstream, I will be moving tcpdump binary from /usr/sbin to /usr/bin, similar to how wireshark does this. If you can think of any reason why not to do this, please let me know. Thanks and regards, -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ 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: EPEL-8 branches requests being rejected
On 10/23/19 7:02 PM, Matthew Miller wrote: > On Wed, Oct 23, 2019 at 09:12:41AM +0200, Jakub Jelen wrote: >> I think this is a problem that the rsh package is in normal RHEL8 (not >> sure in which stream) and if I am right, packages in rhel can not be in >> epel too. > > When we get modularity up and working for EPEL-8, we'll need to figure out > how to handle that, as we want to be able to provide alternate versions as > non-default streams. > > > On another note: rsh? Really? :) Unfortunately, yes :( :D :D -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ 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: EPEL-8 branches requests being rejected
Hi Jakube, yes the package was there in the early RHEL-8.0.0 branch but has been removed. So technically it is not in RHEL-8 even though there are some builds from very long time ago. So perhaps I need to make sure these disappear too? On 10/23/19 9:12 AM, Jakub Jelen wrote: > On Wed, 2019-10-23 at 08:45 +0200, Michal Ruprich wrote: >> Hi, >> >> I am trying to request epel-8 branch for rsh package but the request >> is >> always closed as invalid with this explanation: "The branch in PDC >> already exists". I have no idea what that means. I simply cannot find >> the epel-8 branch anywhere. Could anyone explain this and ideally >> point >> me in the right direction as to where I can find the branch? >> >> Thanks and regards. > Hello, > > I think this is a problem that the rsh package is in normal RHEL8 (not > sure in which stream) and if I am right, packages in rhel can not be in > epel too. > > I can see at least few builds for RHEL8 in brew as well as the rsh as a > bugzilla component. > > Regards, -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ 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
EPEL-8 branches requests being rejected
Hi, I am trying to request epel-8 branch for rsh package but the request is always closed as invalid with this explanation: "The branch in PDC already exists". I have no idea what that means. I simply cannot find the epel-8 branch anywhere. Could anyone explain this and ideally point me in the right direction as to where I can find the branch? Thanks and regards. -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ 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: Looking for an advice on file location in Fedora
On 3/20/19 2:06 PM, Neal Gompa wrote: > On Wed, Mar 20, 2019 at 9:00 AM Zbigniew Jędrzejewski-Szmek > wrote: >> On Wed, Mar 20, 2019 at 10:44:53AM +0100, Michal Ruprich wrote: >>> Hi, >>> >>> I am preparing FRR so that it could be added to Fedora and since there >>> are a lot of experienced packagers here, I would like to ask for an >>> advice. FRR is a fork of quagga and it provides a couple of routing >>> daemons(bgp, isis, odpf, rip, eigrp etc.). Originally in quagga, each >>> daemon had its own binary in /usr/sbin and each daemon could be started >>> via systemctl(including the zebra daemon which is needed to run other >>> routing daemons). In FRR the developers have chosen a different >>> approach. They provide a script that takes care of the start-up of all >>> requested daemons - that means that all daemons are started via a single >>> systemctl command. >> That doesn't sound like a good idea. It seems that they reimplement >> daemon management internally, which usually doesn't go well. >> > I've experienced this from a number of other projects. This is a > seriously bad idea. Have you asked the FRR developers why they feel > they can't use the service management facilities of systemd > effectively? Yes I have, this is their answer: * We see it as “one package”, not as a collection of multiple packages. Ie. Postgresql runs multiple processes, but has 1 startup service/script Similar, we wanted one master init/systemd script to start all daemons. * Systemd is kind of braindead on monitoring and restarting daemons. Things we need, but could not get done with systemd: 1) Our desire is to move to one config file (frr.conf) instead of one per daemon in the near future and in such a config, the startup script needs to reload the configs with vtysh after the daemons are started. This is (not yet) the default for the main distro, but the agreed on future. 2) watchfrr (or on Quagga: watchquagga) is much better in monitoring the daemons than systemd. It has hooks into the daemons to check if they are actually responding (and not just “running”) and trigger restarts as needed. Watchfrr also does watchdog timers back to systemd 3) The order of the startup matters in some cases (i.e. with integrated config where we load config at the end) 4) There is a reload command which can do a non-intrusive reload without restarting any daemons and do a differential config apply. 5) Many distro’s don’t like systemd and we figured that maintaining one (complex) init script is easier than multiple scripts. (I’m still tasked to somehow combine the debian and red hat init scripts into one single one if somehow possible, but didn’t get around it. >>> There are a couple of other scripts that are used for >>> reloading the daemons etc. I am now wondering about where to place all >>> relevant binary files and all the scripts. >> Do the daemons have names that are unique enough to not cause conflicts >> with other packages? If yes, then it should be OK to put them all in >> /usr/bin/. (There's no reason to care about "sbin" vs "bin", since nowadays >> both are included in $PATH.) >> >>> The upstream idea about the location is to put all binary files and all >>> the scripts to /usr/lib/frr/ which does not make much sense to me. >> It is actually a pretty good choice, except that you say that those >> executables are supposed to be called by the users directly. If they >> weren't, or if were only rarely, this upstream decision would be >> appropriate. In particular, there's no effective difference between >> /usr/libexec and /usr/lib/ffr, so using /usr/lib/ffr would be correct. >> > If you're going to stuff binaries in a non-PATH place, > /usr/libexec/frr (I assume FRR is the project name, and not FFR) is > where it should go, full stop. > >>> My >>> first idea was to keep the main script in /usr/sbin and put the rest to >>> /usr/libexec, but that would only make sense if the binaries and scripts >>> were not meant to be run by the user, which is not the case. It is very >>> well possible to start each daemon directly without interfering with >>> systemd or any of the scripts. Same applies for each of the script. >>> >>> So the question is whether it is acceptable to keep the scripts in the >>> /usr/sbin directory together with the binaries or whether I should put >>> them somewhere else? >>> >>> I would be grateful for any ideas about this. Thanks. > In general, this project seems like it needs some help understanding > how servi
Re: Looking for an advice on file location in Fedora
On 3/20/19 1:58 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Mar 20, 2019 at 10:44:53AM +0100, Michal Ruprich wrote: >> Hi, >> >> I am preparing FRR so that it could be added to Fedora and since there >> are a lot of experienced packagers here, I would like to ask for an >> advice. FRR is a fork of quagga and it provides a couple of routing >> daemons(bgp, isis, odpf, rip, eigrp etc.). Originally in quagga, each >> daemon had its own binary in /usr/sbin and each daemon could be started >> via systemctl(including the zebra daemon which is needed to run other >> routing daemons). In FRR the developers have chosen a different >> approach. They provide a script that takes care of the start-up of all >> requested daemons - that means that all daemons are started via a single >> systemctl command. > That doesn't sound like a good idea. It seems that they reimplement > daemon management internally, which usually doesn't go well. > >> There are a couple of other scripts that are used for >> reloading the daemons etc. I am now wondering about where to place all >> relevant binary files and all the scripts. > Do the daemons have names that are unique enough to not cause conflicts > with other packages? If yes, then it should be OK to put them all in > /usr/bin/. (There's no reason to care about "sbin" vs "bin", since nowadays > both are included in $PATH.) > >> The upstream idea about the location is to put all binary files and all >> the scripts to /usr/lib/frr/ which does not make much sense to me. > It is actually a pretty good choice, except that you say that those > executables are supposed to be called by the users directly. If they > weren't, or if were only rarely, this upstream decision would be > appropriate. In particular, there's no effective difference between > /usr/libexec and /usr/lib/ffr, so using /usr/lib/ffr would be correct. Well I meant that they could be called directly but upstream idea is that they should not be. They want them all to be controlled by the main frr process. > >> My >> first idea was to keep the main script in /usr/sbin and put the rest to >> /usr/libexec, but that would only make sense if the binaries and scripts >> were not meant to be run by the user, which is not the case. It is very >> well possible to start each daemon directly without interfering with >> systemd or any of the scripts. Same applies for each of the script. >> >> So the question is whether it is acceptable to keep the scripts in the >> /usr/sbin directory together with the binaries or whether I should put >> them somewhere else? >> >> I would be grateful for any ideas about this. Thanks. > Zbyszek > ___ > 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 -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ 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
Looking for an advice on file location in Fedora
Hi, I am preparing FRR so that it could be added to Fedora and since there are a lot of experienced packagers here, I would like to ask for an advice. FRR is a fork of quagga and it provides a couple of routing daemons(bgp, isis, odpf, rip, eigrp etc.). Originally in quagga, each daemon had its own binary in /usr/sbin and each daemon could be started via systemctl(including the zebra daemon which is needed to run other routing daemons). In FRR the developers have chosen a different approach. They provide a script that takes care of the start-up of all requested daemons - that means that all daemons are started via a single systemctl command. There are a couple of other scripts that are used for reloading the daemons etc. I am now wondering about where to place all relevant binary files and all the scripts. The upstream idea about the location is to put all binary files and all the scripts to /usr/lib/frr/ which does not make much sense to me. My first idea was to keep the main script in /usr/sbin and put the rest to /usr/libexec, but that would only make sense if the binaries and scripts were not meant to be run by the user, which is not the case. It is very well possible to start each daemon directly without interfering with systemd or any of the scripts. Same applies for each of the script. So the question is whether it is acceptable to keep the scripts in the /usr/sbin directory together with the binaries or whether I should put them somewhere else? I would be grateful for any ideas about this. Thanks. Michal Ruprich ___ 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: Problem with portaudio linking
On 1/4/19 12:19 PM, Michael Schwendt wrote: > On Fri, 4 Jan 2019 10:41:46 +0100, Michal Ruprich wrote: > >> Hi, >> >> has anyone encountered a problem on F28 when building a package that >> uses portaudio? I was building newer version of wireshark a month ago >> and -lportaudio worked fine. Now the build with the same version fails >> with message 'checking for Pa_Initialize in -lportaudio... no' and >> 'configure: error: Linking with libportaudio failed'. The build still >> works on F29 and in Rawhide, only F28 hits this issue. Anyone else has >> seen this happening? > Have you tried a build with > > %configure || cat config.log Thanks, I didn't think of that. Turns out that it needs jack-audio-connection-kit as a dependency. > > to check why the library linking test has failed? > ___ > 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 -- Michal Ruprich Associate Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ 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
Problem with portaudio linking
Hi, has anyone encountered a problem on F28 when building a package that uses portaudio? I was building newer version of wireshark a month ago and -lportaudio worked fine. Now the build with the same version fails with message 'checking for Pa_Initialize in -lportaudio... no' and 'configure: error: Linking with libportaudio failed'. The build still works on F29 and in Rawhide, only F28 hits this issue. Anyone else has seen this happening? Thanks. -- Michal Ruprich Associate Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ 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
Firefox lost my session after update
Anyone else has experienced this? I rebooted my laptop after some time and newer version of Firefox(60.0.2-1.f27) kicked in. Unfortunately my session is lost and I cannot seem to be able to restore it in any way. From what I've heard I am not the only one here in the office who ran into this. -- Michal Ruprich Associate Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ 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/PAJHHMBAWDSSOJDPSHEETUQFNB7IUJWE/
Broken dependencies for tetex in Rawhide?
I'm getting this error when building a package with dependency on tetex in Fedora Rawhide: Problem: package texlive-scheme-tetex-7:svn44187-4.fc29.noarch requires texlive-collection-plaingeneric, but none of the providers can be installed - conflicting requests - nothing provides texlive-autoaligne needed by texlive-collection-plaingeneric-7:svn44986-4.fc29.noarch Is this package broken in Rawhide? -- Michal Ruprich Associate Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Changes in wireshark package name
On 03/06/2018 03:40 PM, Kevin Kofler wrote: > Michal Ruprich wrote: >> the plan to drop the GTK+ GUI [1] was approved by FESCO, so I will be >> dropping the wireshark-gtk package in rawhide(currently F29). Also I >> would like to propose that we change the name of wireshark-qt. There are >> three packages now - wireshark-cli, wireshark-gtk and wireshark-qt. >> Since the wireshark-gtk is going away I would like to suggest that we >> change the wireshark-qt to something more generic like wireshark-gui. If >> you feel like there is a reason why I should not do that, please just >> respond to this email. > Why not just "wireshark", if the CLI has its own name anyway? > > Kevin Kofler Good point, wireshark-qt will just be wireshark. Thanks > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Michal Ruprich Associate Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] Changes in wireshark package name
Hi, the plan to drop the GTK+ GUI [1] was approved by FESCO, so I will be dropping the wireshark-gtk package in rawhide(currently F29). Also I would like to propose that we change the name of wireshark-qt. There are three packages now - wireshark-cli, wireshark-gtk and wireshark-qt. Since the wireshark-gtk is going away I would like to suggest that we change the wireshark-qt to something more generic like wireshark-gui. If you feel like there is a reason why I should not do that, please just respond to this email. Thanks. [1] https://fedoraproject.org/wiki/Changes/Drop_Legacy_GTK+_GUI_in_wireshark -- Michal Ruprich Associate Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] Package wireshark-gtk going away
Hi, the wireshark-gtk is no longer supported by the upstream since wireshark-2.4.0. You may have noticed that there is new GUI based on Qt since wireshark-2.0. This GUI will become default and the GTK-based GUI will be dropped and no longer provided. This change should appear in Fedora 29. -- Michal Ruprich Associate Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
[HEADS UP] Package wireshark-gtk going away
Hi, the wireshark-gtk is no longer supported by the upstream since wireshark-2.4.0. You may have noticed that there is new GUI based on Qt since wireshark-2.0. This GUI will become default and the GTK-based GUI will be dropped and no longer provided. This change should appear in Fedora 29. -- Michal Ruprich Associate Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Removal of systemd-units
> mruprich net-tools net-tools rsync Done for both packages. -- Michal Ruprich Associate Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
