Re: Orphaning The Mana World (tmw and tmw-music)
On Jan 11, 2016 22:23, "Martin Gieseking" wrote: > > Am 11.01.2016 um 20:53 schrieb Erik Schilling: > > After a short discussion with upstream they told me that they ship the > > branding for tmw inside of the manaplus sources. So it would probably be > > the easiest to simply create a tmw package as subpackage of the > > manaplus.spec. > > > > But well... I do not have the time and will to keep track of the > > manaplus release scheme so I guess there is nothing I can do here. > > > Thanks for contacting upstream about the current state of TMW and for > thinking about to take the package. Since you don't have enough time to > maintain it either, we should drop it for now. Maybe there will be > someone interested in the package anytime later. It is not that critical that the branding package is gone since it is still possible to launch the game via Manaplus directly (I would assume that most people do it that way anyway). Only the bit of branding is gone. But well... Regards, Erik -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Rules regarding whitespace inside .spec files
On 01/13/2016 08:24 AM, Luya Tshimbalanga wrote:
> In general, leading whitespace is only allowed when making conditional
> statement or using backslash like these following examples:
>
> --- Example #1 ---
> %if (0%{?fedora} && 0%{?fedora} < 19) || (0%{?rhel} && 0%{?rhel} < 7)
> --vendor="fedora" \
> %endif
> --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
> %{name}.desktop
>
> --- Example #2 ---
> for f in scribus/plugins/scriptplugin/{samples,scripts}/*.py
> do
> sed '1{/#!\/usr\/bin\/env\|#!\/usr\/bin\/python/d}' $f > $f.new
> touch -r $f $f.new
> mv $f.new $f
> done
> --
But these are part of scriptlets, so whitespace is passed to the shell,
which then ignores it (except where it is significant, like the line
ending before the “do”). I don't think it has to do with backslashes or
conditional/control flow statements.
Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Rules regarding whitespace inside .spec files
On 12/01/16 10:18 PM, Andrew Toskin wrote:
> I'm new to RPM packaging. I've recently forked a repository, and one of the
> first things I tried to do was clean up formatting of the .spec file.
> Particularly the %if blocks were hard to follow because the previous author
> did not use any indentation at all. However, it seems like maybe indentation
> breaks tags. %if blocks that only contained other %macros inside seem to work
> okay, but if I have any leading whitespace on the lines for tags such as
> `Source1:` I get errors like this...
>
>> error: line 102: Unknown tag: Source1: firefox-45.0a2.tar.bz2
> ...and removing the leading whitespace removes the error.
>
> I'm having a hard time finding anything that explicitly says whether or not
> leading whitespace is allowed in the spec file, so I'm hoping that I'm just
> making some silly and simple mistake. Otherwise, not being able to indent
> inside %if blocks is going to make working on this spec file more painful
> than it could / should be.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Hello Andrew,
In general, leading whitespace is only allowed when making conditional
statement or using backslash like these following examples:
--- Example #1 ---
%if (0%{?fedora} && 0%{?fedora} < 19) || (0%{?rhel} && 0%{?rhel} < 7)
--vendor="fedora" \
%endif
--dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
%{name}.desktop
--- Example #2 ---
for f in scribus/plugins/scriptplugin/{samples,scripts}/*.py
do
sed '1{/#!\/usr\/bin\/env\|#!\/usr\/bin\/python/d}' $f > $f.new
touch -r $f $f.new
mv $f.new $f
done
--
Hope it helps.
--
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide 20160112 compose check report
Missing expected images: Kde disk raw armhfp No images in this compose but not Rawhide 20160111 No images in Rawhide 20160111 but not this. Failed openQA tests: 4 of 66 ID: 2985Test: i386 kde_live default_install URL: https://openqa.fedoraproject.org/tests/2985 ID: 2983Test: x86_64 workstation_live base_services_start URL: https://openqa.fedoraproject.org/tests/2983 ID: 2979Test: x86_64 kde_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/2979 ID: 2978Test: x86_64 kde_live default_install URL: https://openqa.fedoraproject.org/tests/2978 Passed openQA tests: 62 of 66 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Rules regarding whitespace inside .spec files
I'm new to RPM packaging. I've recently forked a repository, and one of the first things I tried to do was clean up formatting of the .spec file. Particularly the %if blocks were hard to follow because the previous author did not use any indentation at all. However, it seems like maybe indentation breaks tags. %if blocks that only contained other %macros inside seem to work okay, but if I have any leading whitespace on the lines for tags such as `Source1:` I get errors like this... > error: line 102: Unknown tag: Source1: firefox-45.0a2.tar.bz2 ...and removing the leading whitespace removes the error. I'm having a hard time finding anything that explicitly says whether or not leading whitespace is allowed in the spec file, so I'm hoping that I'm just making some silly and simple mistake. Otherwise, not being able to indent inside %if blocks is going to make working on this spec file more painful than it could / should be. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Announce of package to mark as Orphan – repoview – rpmdepsize – snake - revisor
On Tue, Jan 12, 2016 at 7:25 PM, Nico Kadel-Garcia wrote: > On Fri, Jan 8, 2016 at 10:37 AM, Sérgio Basto wrote: >> On Sex, 2016-01-08 at 08:54 -0500, Jaroslav Mracek wrote: >>> Hi everybody, >>> >>> I would like to set following packages as Orphan due to that upstream >>> is dead or maintainers do not respond: >>> >>> repoview >> >> have we a replace for repoview ? > > Does anyone actually like it? I find it to be confusing eye candy, > unnecessary and interfering with basic content reviews, compared to a > flat filename based file list. I deliberately exclude "repoview" from > all repository mirrors. It would be nice if we had a better way to generate pages on packages in a repository based on the metadata, in a lightweight fashion. I've kinda poked at it to update it myself[0], but there's stuff that has to be fixed: the Kid templates need to be replaced, the usage of SQLite metadata needs to be replaced with parsing the XML data, and the dependency on yum needs to be killed. The dependency on yum was easy to kill, as I was able to replace yum.comps with python-libcomps, but the other stuff is much harder. [0]: https://gitlab.com/Conan_Kudo/repoview -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: keepassx 2.0?
On 12/01/16 22:59 +, Jonathan Wakely wrote: The old version could be added as keepassx1, or just via COPR, for those who still want it. I've created a COPR with keepassx 0.4.4 builds for F22 and F23: https://copr.fedoraproject.org/coprs/jwakely/keepassx1/build/153188/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Announce of package to mark as Orphan – repoview – rpmdepsize – snake - revisor
On Fri, Jan 8, 2016 at 10:37 AM, Sérgio Basto wrote: > On Sex, 2016-01-08 at 08:54 -0500, Jaroslav Mracek wrote: >> Hi everybody, >> >> I would like to set following packages as Orphan due to that upstream >> is dead or maintainers do not respond: >> >> repoview > > have we a replace for repoview ? Does anyone actually like it? I find it to be confusing eye candy, unnecessary and interfering with basic content reviews, compared to a flat filename based file list. I deliberately exclude "repoview" from all repository mirrors. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Golang 1.6
On Tue, Jan 12, 2016 at 5:30 PM, Matthew Miller wrote: > On Tue, Jan 12, 2016 at 01:31:30AM +, Peter Robinson wrote: >> Will there be an ABI guaranteed beta or RC so that this can be >> complete before branching as per the schedule [1]? All major rebases >> should be complete prior to branching. >> [1] https://fedoraproject.org/wiki/Releases/24/Schedule > > Since everything is statically linked, the ABI isn't really a factor. It is if it changes between say beta and GA because it'll still all then need another rebuild, hence the question. > It sure would be nice to land before the mass rebuild, though -- > otherwise it's a second mini-rebuild of all the Go things. Actually two rebuilds because we'll likely have branched and it has to then go through bodhi if it's much later than that, so an order of magnitude more work hence why all rebases that need rebuilds happen before branching. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: keepassx 2.0?
So how should the maintainer proceed? The policy was violated, but it's done now. F23 has already been updated, F22 has an update in testing now (with negative karma). The old version could be added as keepassx1, or just via COPR, for those who still want it. Since some people will already have the new version from F22's updates-testing repo maybe it's too late for F22 as well and it should be pushed to stable. In that case keepassx1 would be useful for F22 too. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
python-rpm-macros - splitting out the macros
On 01/08/2016 11:27 AM, bugzi...@redhat.com wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1294904 > > Antonio Trande changed: > >What|Removed |Added > > Flags|fedora-review? |fedora-review+ > > > > --- Comment #12 from Antonio Trande --- > Package approved. > I still have heard nothing from the main python maintainers, and I'd like to get some kind of an ack for the following plan: - Dropping the python3-pkgversion-macros package, replaced with python-srpm-macros from above and required by redhat-rpm-config (in Fedora) and epel-rpm-macros (in EPEL). - Dropping the python-macros sub-package from python, replace by Requires: python-rpm-macros from above package. python3 requires this as well. - Dropping macros.python2 from python-devel, replaced with Requires: python2-rpm-macros from above package. - Dropping macros.python3 from python3-devel, replaced with Requires: python3-rpm-macros from above package. This achieves the goal of decoupling modifying/updating the python macros from updating the main python package, which has become a serious hindrance to developing new python rpm macros. The reviewed package contains the Fedora macros. macros will be changed on the EPEL branches. I've requested a side tag to do the build in here - https://fedorahosted.org/rel-eng/ticket/6331 as I think the timing is tricky and the possibility of breaking the buildroot moderate. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: keepassx 2.0?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/12/2016 03:38 PM, Martin Ueding wrote: > I was rather surprised by this too. When the UI changed I was > already a bit sceptical as KeePassX has not changed in like five > years. When it did not open the old database I knew that I was > served version 2. A short look in the dnf automatic update emails > confirmed that. > > The mid-release break was unexpected. I have converted my database > now and kept the old one. As there is nothing wrong with 2.0 and > most of my devices are the same Fedora 23, I will be able to work > with the new database. > > I have thought that the version 2.0 would come eventually, just > not mid-release. So even if there would be a package for the old > version, I would not go back as the new one seems to work just as > well. +1. My thoughts exactly. Despite the fact that v2 was a surprise, no harm done since I used the import function (messages were clear) and I still have the older file untouched. Having said that, I would not want to go back to the older version either. My two cents .. - -- GPG Key - E5C8BC67 - --- -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWlXy1AAoJEHE/1K3lyLxntU0QANXbX7F6N1+wJ9VmpUe9FLHj PsCdywWIik6sLNLV5fesxUiEKv+N5BOaoZJMOEffN9CXczN6nTzpQDk7FC7wNDqZ D9UkbvIXNyjX9itAxBSZhd7yKin5paEMy8zYOp1or5vGMeFhf2Z7HY7Po/yCK032 dtdLLlGb1tzKF2qFajzLKDQRkl5RE0EaMLHhvUCmMmw1QF2v1CvII65BtBff8kW4 Gsrxi6kheNYvfJxeHskDHRIETSph6yHiEtaWoGsy6NTg5qKu6tct5yuNrxYHTed2 T8nua+3NqyTIfVY4zXsSy7/e/Ba3TPlJN4o/jaeeDrpQIZ7g45ktPw3U/XrIZcSk OG92vu81DHMo/fZ/9UFcLuczNGAsQgE8bPACpg9sUFJSJTatcjKOLQ2Sre4xezCj hFc8LHHAJhtHs4oZYQ6gGpjDQ1q+lYsPAhLlViBC9IzGHpYXdBBgGpVQHc8v+k4Q DCGl+m2caqvCR6pdixEtB7EWdsp2Xg7OYAGg+Fsl6mVgFmuceQZEsGnb9rcs8z74 bcvOQTLQTVr3PFsV7lFoodsebCn6m545PrCes4bzYyegpIh49cfI1p2+p4yD18f1 uEWD3quyehNwo17YPD7WY3N7yOvkWE+0eynM0KA3FTBL1YuTCRkoj/bS3I5pXr4M omj/NBUjAmKKJ6sEfw+r =DZH4 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: keepassx 2.0?
I was rather surprised by this too. When the UI changed I was already a bit sceptical as KeePassX has not changed in like five years. When it did not open the old database I knew that I was served version 2. A short look in the dnf automatic update emails confirmed that. The mid-release break was unexpected. I have converted my database now and kept the old one. As there is nothing wrong with 2.0 and most of my devices are the same Fedora 23, I will be able to work with the new database. I have thought that the version 2.0 would come eventually, just not mid-release. So even if there would be a package for the old version, I would not go back as the new one seems to work just as well. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: 4.3 rebase in F23 updates-testing
On Tue, Jan 12, 2016 at 2:08 PM, Mattia Verga wrote: > Il 07/01/2016 20:30, Tomasz Torcz ha scritto: >> >> On Thu, Jan 07, 2016 at 01:33:22PM -0500, Josh Boyer wrote: >>> >>> Hello, >>> >>> The 4.3.3 kernel has been pushed to updates-testing for F23. As of >>> right now, it has a +12 karma score. Given that it is a major release >>> rebase, we're going to wait at least a few days to see how it fares. >>> >>> If you are so inclined, testing would be appreciated. As usual, >>> please give karma as appropriate but we would appreciate it if you >>> only give negative karma for new, not reported issues and with a bug >>> link associated. If a bug is fixed, we have marked it as such. If it >>> isn't, we haven't and giving negative karma for those known issues >>> simply prevents fixes from getting into the hands of other users. >>> >> Please note there seem to be a btrfs regression in since 4.3: >> namely fstrim could discard beginning of the disk, removing the >> bootloader. This commit fixes the issue: >> >> >> http://git.kernel.org/cgit/linux/kernel/git/fdmanana/linux.git/commit/?h=integration-4.5&id=7b6cb6618b45bb383f9336ec89df5f1f31f9935b >> > So, is it safe to install kernel 4.3.3-300? I see it's now in stable repo, > but I think it doesn't carry the commit above... The commit above isn't in any released kernel, Fedora or upstream or otherwise. It was only added to the main btrfs maintainer's tree about a day ago. As far as I understand the bug, it only happens if you have the bootloader installed in the root partition (not a separate /boot) and you run an fstrim on the whole partition (fstrim /) either manually or from a system script or such. I suppose it would possibly happen if you have the bootloader installed in a btrfs /boot partition and ran fstrim on that too. However, Fedora doesn't support booting from a btrfs filesystem at the moment and typical installs create a separate /boot partition that is ext4. I may have some details wrong and would gladly be corrected if so. We'll pick up the fix once it lands in Linus' tree. Until then, the safety is mostly determine by that of btrfs in general. Opinions vary. josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
Should we split the discussion about socket activation in another thread. And discuss zookeeper service specifically here. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: 4.3 rebase in F23 updates-testing
Il 07/01/2016 20:30, Tomasz Torcz ha scritto: On Thu, Jan 07, 2016 at 01:33:22PM -0500, Josh Boyer wrote: Hello, The 4.3.3 kernel has been pushed to updates-testing for F23. As of right now, it has a +12 karma score. Given that it is a major release rebase, we're going to wait at least a few days to see how it fares. If you are so inclined, testing would be appreciated. As usual, please give karma as appropriate but we would appreciate it if you only give negative karma for new, not reported issues and with a bug link associated. If a bug is fixed, we have marked it as such. If it isn't, we haven't and giving negative karma for those known issues simply prevents fixes from getting into the hands of other users. Please note there seem to be a btrfs regression in since 4.3: namely fstrim could discard beginning of the disk, removing the bootloader. This commit fixes the issue: http://git.kernel.org/cgit/linux/kernel/git/fdmanana/linux.git/commit/?h=integration-4.5&id=7b6cb6618b45bb383f9336ec89df5f1f31f9935b So, is it safe to install kernel 4.3.3-300? I see it's now in stable repo, but I think it doesn't carry the commit above... -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unresponsive maintainer procedure for tuxbrewr
On Tue, 12 Jan 2016 16:27:03 +0100, Sven Lankes wrote: > As I understand it, your sponsor is supposed to look after your commits. Not forever, though. Sponsorship is not a life-time duty, and monitoring git commits isn't either. It's not even mentioned as a responsibility. There are sponsors who don't do anything like that after approval a single review request. Strange things can happen, too. Sometimes, packagers submit flawless packages for review, and once included in the collection, after some months the packagers start messing up the packages in various ways. They would not pass a review anymore. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
Am 12.01.2016 um 19:50 schrieb Lennart Poettering: On Tue, 12.01.16 19:48, Reindl Harald (h.rei...@thelounge.net) wrote: Am 12.01.2016 um 19:44 schrieb Lennart Poettering: On Tue, 12.01.16 19:37, Reindl Harald (h.rei...@thelounge.net) wrote: That said, of course, this is not obvious at first, hence since quite some time "systemctl stop" will actually explain this to you: if you stop a daemon, but leave its socket running, then you'll get a friendly message telling you about this, and suggesting you the right command line to terminate the socket too. as soon as you are able to print out such a "friendly message" you are also able to imply it automatically Well, sure, but that's something we don't want to do, as people should be able to stop units and their triggering units separately and individually. I'd be willing to take a patch that adds a new job mode though, that recursively includes stop/start jobs for all triggering units. i.e. "systemctl --job-mode=triggering foo.service" or so. That would certainly be a useful enhancement, but should not be the default. IT SHOULD be the default Well, no. And spelling this out in caps won't help. This is nothing we can just change, even if we'd want to. It's exposed stable behaviour. Sorry surely, you could in systemd recognize that the socket is ignored for now, automatically started with the next "systemctl start service" there is a huge difference between * socket enabled, service not running * socket enabled, service stopped by the admin in case 1 it's exposed behavior to start the service on the first request, in case 2 it's the explicit wish of the admin SHUT DOWN a service - with the still enabled and listening socket that wish is worth *nothing* because there is no difference between a running netwrok waware service or a stopped one with a listening socket fire it up by the first request "systemctl stop service" in fact does *nothing* what makes that beavior worst is that "systemctl stop service.service service.socket" enorces the admin not just start the service after maintain operatins - he needs also to start the socket a "systemctl stop service" with implicit stop the socket and after maintainence "systemctl start service" autmatically start the socket if it was implicit stopped would be the desired behavior for anybody in real life signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
> > Please don't top-post [1] > Sorry I was on mobile gmail client. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On Tue, 12.01.16 19:48, Reindl Harald (h.rei...@thelounge.net) wrote: > > > Am 12.01.2016 um 19:44 schrieb Lennart Poettering: > >On Tue, 12.01.16 19:37, Reindl Harald (h.rei...@thelounge.net) wrote: > > > >>>That said, of course, this is not obvious at first, hence since quite > >>>some time "systemctl stop" will actually explain this to you: if you > >>>stop a daemon, but leave its socket running, then you'll get a > >>>friendly message telling you about this, and suggesting you the right > >>>command line to terminate the socket too. > >> > >>as soon as you are able to print out such a "friendly message" you are also > >>able to imply it automatically > > > >Well, sure, but that's something we don't want to do, as people should > >be able to stop units and their triggering units separately and > >individually. > > > >I'd be willing to take a patch that adds a new job mode though, that > >recursively includes stop/start jobs for all triggering > >units. i.e. "systemctl --job-mode=triggering foo.service" or so. That > >would certainly be a useful enhancement, but should not be the > >default. > > IT SHOULD be the default Well, no. And spelling this out in caps won't help. This is nothing we can just change, even if we'd want to. It's exposed stable behaviour. Sorry, Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
Am 12.01.2016 um 19:44 schrieb Lennart Poettering: On Tue, 12.01.16 19:37, Reindl Harald (h.rei...@thelounge.net) wrote: That said, of course, this is not obvious at first, hence since quite some time "systemctl stop" will actually explain this to you: if you stop a daemon, but leave its socket running, then you'll get a friendly message telling you about this, and suggesting you the right command line to terminate the socket too. as soon as you are able to print out such a "friendly message" you are also able to imply it automatically Well, sure, but that's something we don't want to do, as people should be able to stop units and their triggering units separately and individually. I'd be willing to take a patch that adds a new job mode though, that recursively includes stop/start jobs for all triggering units. i.e. "systemctl --job-mode=triggering foo.service" or so. That would certainly be a useful enhancement, but should not be the default. IT SHOULD be the default when i say "systemctl stop service" i mean that unconditionally and there is no point in for example stop a webserver manually while the socket would fire up the service on the next request there is *really* no point for such a behavior I am pretty sure this makes a lot of sense the way it is, and is sufficiently well self-explanatory. no, it violates the prnciple of least surprise and that won't change Well, let's agree to disagree on this one well, than accept that i refuse to use socket activated services and recommend that to anybody else until bheavior changes signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On Tue, 12.01.16 19:37, Reindl Harald (h.rei...@thelounge.net) wrote: > >That said, of course, this is not obvious at first, hence since quite > >some time "systemctl stop" will actually explain this to you: if you > >stop a daemon, but leave its socket running, then you'll get a > >friendly message telling you about this, and suggesting you the right > >command line to terminate the socket too. > > as soon as you are able to print out such a "friendly message" you are also > able to imply it automatically Well, sure, but that's something we don't want to do, as people should be able to stop units and their triggering units separately and individually. I'd be willing to take a patch that adds a new job mode though, that recursively includes stop/start jobs for all triggering units. i.e. "systemctl --job-mode=triggering foo.service" or so. That would certainly be a useful enhancement, but should not be the default. > >I am pretty sure this makes a lot of sense the way it is, and is > >sufficiently well self-explanatory. > > no, it violates the prnciple of least surprise and that won't change Well, let's agree to disagree on this one. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
Am 12.01.2016 um 19:30 schrieb Lennart Poettering: On Tue, 12.01.16 18:54, Reindl Harald (h.rei...@thelounge.net) wrote: Also, what happens if the daemon is configured to listen on some different port? Or on multiple ports? Are you parsing the daemon's config file too to figure out what to watch for? YUCK! the Fedora myqld unit does, mine is simplified the systemd-behavior that manual "systemctl stop whatever.service" don't prevent socket activation and fireup again the service is a systemd problem *you* have to solve if you want widely adopted usage of socket activation That's hardly a "problem", as I see it. for you What you should be invoking is "systemctl stop whatever.socket whatever.service", which terminates both the daemon and the listening socket. I think that's pretty easy to grok for most folks, as long as you realized the logic behind it once. it's not a matter of grok something it's a matter of not every daemon has a socket and hwat does the user express with a command - you aregued the same way about making "systemctl stop sshd" versus "systemctl stop sshd.service" work as default That said, of course, this is not obvious at first, hence since quite some time "systemctl stop" will actually explain this to you: if you stop a daemon, but leave its socket running, then you'll get a friendly message telling you about this, and suggesting you the right command line to terminate the socket too. as soon as you are able to print out such a "friendly message" you are also able to imply it automatically I am pretty sure this makes a lot of sense the way it is, and is sufficiently well self-explanatory. no, it violates the prnciple of least surprise and that won't change signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On 12/01/16 19:33, Muayyad AlSadi wrote: Will I do agree it's a hack. But it's better than forking in bash. And usually I don't care about the exact time socket/port is active because zookeeper is supposed to handle fail over. [ the rest below..] Please don't top-post [1] Cheers! --alec [1] https://fedoraproject.org/wiki/Mailing_list_guidelines -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
Will I do agree it's a hack. But it's better than forking in bash. And usually I don't care about the exact time socket/port is active because zookeeper is supposed to handle fail over. On Jan 12, 2016 7:54 PM, "Reindl Harald" wrote: > > > Am 12.01.2016 um 17:41 schrieb Lennart Poettering: > >> On Tue, 12.01.16 17:16, Muayyad AlSadi (als...@gmail.com) wrote: >> >> well. But if you can double fork() in Java you should be fine and can >>> >>> it seems that zookeeper is doing the fork in the bash script using nohub >>> not in java >>> >>> when it finished setting up its listening socket. You cannot script >>> >>> typically I loop using "lsof" or "nc" >>> >> >> Such sleep loops are ugly and a hack. It would be much better to fix >> this properly with a clean notification. >> >> Doing such sleep loops will just help keeping up java's bad rep for >> being slow... >> >> Also, what happens if the daemon is configured to listen on some >> different port? Or on multiple ports? Are you parsing the daemon's >> config file too to figure out what to watch for? YUCK! >> > > the Fedora myqld unit does, mine is simplified > > the systemd-behavior that manual "systemctl stop whatever.service" don't > prevent socket activation and fireup again the service is a systemd problem > *you* have to solve if you want widely adopted usage of socket activation > > > -- > 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
Re: is there a reason for starting zookeeper.service in background?
On Tue, 12.01.16 18:54, Reindl Harald (h.rei...@thelounge.net) wrote: > >Also, what happens if the daemon is configured to listen on some > >different port? Or on multiple ports? Are you parsing the daemon's > >config file too to figure out what to watch for? YUCK! > > the Fedora myqld unit does, mine is simplified > > the systemd-behavior that manual "systemctl stop whatever.service" don't > prevent socket activation and fireup again the service is a systemd problem > *you* have to solve if you want widely adopted usage of socket activation That's hardly a "problem", as I see it. What you should be invoking is "systemctl stop whatever.socket whatever.service", which terminates both the daemon and the listening socket. I think that's pretty easy to grok for most folks, as long as you realized the logic behind it once. That said, of course, this is not obvious at first, hence since quite some time "systemctl stop" will actually explain this to you: if you stop a daemon, but leave its socket running, then you'll get a friendly message telling you about this, and suggesting you the right command line to terminate the socket too. I am pretty sure this makes a lot of sense the way it is, and is sufficiently well self-explanatory. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Changes in F24 schedule - two weeks slip
On Tue, Jan 12, 2016 at 07:22:46PM +0100, Jan Kurik wrote: > > Jan, previously when we've updated the schedule, the previous dates for > > each milestone are retained with a strikethrough (see > > https://fedoraproject.org/wiki/Releases/23/Schedule). Are we not doing > > that intentionally this time because we're so early in the process? > OK, I will update the schedule in this way. Thanks for letting me > know. I did not know it is a "best practice" to do it so. I find it convenient because people ask me about the schedule _a lot_. :) -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Changes in F24 schedule - two weeks slip
On Tue, Jan 12, 2016 at 6:33 PM, Matthew Miller wrote: > On Tue, Jan 12, 2016 at 03:23:55AM +0100, Jan Kurik wrote: >> schedule for 2 weeks. Please check the updated schedule at >> https://fedoraproject.org/wiki/Releases/24/Schedule#Key_Milestones . >> Dates for the most important milestones follows: > > Jan, previously when we've updated the schedule, the previous dates for > each milestone are retained with a strikethrough (see > https://fedoraproject.org/wiki/Releases/23/Schedule). Are we not doing > that intentionally this time because we're so early in the process? OK, I will update the schedule in this way. Thanks for letting me know. I did not know it is a "best practice" to do it so. Regards, Jan > -- > Matthew Miller > > Fedora Project Leader > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: keepassx 2.0?
On 12/01/16 12:54 -0500, Chuck Anderson wrote: Given that people have already had their databases upgraded to .kdbx (but the v1 .kdb file is still there), instead of downgrading keepassx which is now at v2, you could inroduce a new keepassx1 package. It might be cleaner that way now that the v2 package has already gone out. Yes, although as I noted elsewhere in this thread, the update hasn't been pushed to stable for F22 yet, only updates-testing. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[EPEL-devel] Re: LibRaw is in EPEL testing and also in Base
On 01/12/2016 11:54 AM, Orion Poplawski wrote: On 01/12/2016 08:28 AM, Johnny Hughes wrote: 'LibRaw-0.17.1-3.el7.x86_64 (epel-testing)' and 'LibRaw-0.14.8-5.el7.20120830git98d925.x86_64 (@base/$releasever)' are conflicting I think there is some confusion around this. It seems that it may have been removed from RHEL7.2 but not CentOS/SL? There is no reference to libraw I could find in the RHEL7.2 release notes.. typically removed packages are documented there. Pat ___ epel-devel mailing list epel-de...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-de...@lists.fedoraproject.org
Re: keepassx 2.0?
On 12/01/16 18:50 +0100, Jens Lody wrote: keepassx 2 uses kdbx file-ending, while keepassx 0.4 uses kdb. I have updated and converted, but the old file is still present and untouched. Oh good! So then there's even less reason not to support parallel installations of both versions. The only question in my mind is whether the new or old version should be called "keepassx", i.e. would it be keepassx1-0.4.4 and keepassx-2.0.0, or keepassx-0.4.4 and keepassx2-2.0.0 The answer might be different for F23 and F22, because the update to 2.0.0 has already been pushed to stable for F23, but not yet for F22. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: keepassx 2.0?
On Tue, Jan 12, 2016 at 10:41:24AM +, Jonathan Wakely wrote: > I'm concerned by this update too. > > The latest post in Bugzilla says: > > (In reply to Francesco Frassinelli (frafra) from comment #35) > >(In reply to Ed Marshall from comment #33) > >> (and, obviously, send email to the mailing list, so users are > >> actually > >> notified this time rather than getting a surprise breaking upgrade > >> out of > >> the blue) > > > >I can't downgrade keepassx because many people upgraded their > >database > >(comment #34). > > Those people are presumably happy with version 2 (or are stuck with it > now). But there are other people refusing to upgrade because of this. > > A possible solution is to include both keepassx-0.4.4 and > keepassx2-2.0.0 in F22 and F23, so people can choose which version to > use based on their preference (and whether they've already upgraded > their databases). > > >I could provide a keepassx2 subpackage which replaces keepassx = > >2.0.0, but > >I'm not sure about how to handle Obsoletes/Provides in this case. > > Couldn't both be installed at the same time (if the binaries are > renamed)? You just can't use the same .kdb file with both versions. Given that people have already had their databases upgraded to .kdbx (but the v1 .kdb file is still there), instead of downgrading keepassx which is now at v2, you could inroduce a new keepassx1 package. It might be cleaner that way now that the v2 package has already gone out. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
Am 12.01.2016 um 17:41 schrieb Lennart Poettering: On Tue, 12.01.16 17:16, Muayyad AlSadi (als...@gmail.com) wrote: well. But if you can double fork() in Java you should be fine and can it seems that zookeeper is doing the fork in the bash script using nohub not in java when it finished setting up its listening socket. You cannot script typically I loop using "lsof" or "nc" Such sleep loops are ugly and a hack. It would be much better to fix this properly with a clean notification. Doing such sleep loops will just help keeping up java's bad rep for being slow... Also, what happens if the daemon is configured to listen on some different port? Or on multiple ports? Are you parsing the daemon's config file too to figure out what to watch for? YUCK! the Fedora myqld unit does, mine is simplified the systemd-behavior that manual "systemctl stop whatever.service" don't prevent socket activation and fireup again the service is a systemd problem *you* have to solve if you want widely adopted usage of socket activation signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: keepassx 2.0?
Am Tue, 12 Jan 2016 10:41:24 + schrieb Jonathan Wakely : > On 12/01/16 01:47 -0800, Ed Marshall wrote: > >Bringing this discussion to the mailing list, since it's all > >apparently happened in bugzilla until now (and I only found out when > >I updated this evening). > > > >For reference: https://bugzilla.redhat.com/show_bug.cgi?id=1282825 > > > >This update (0.4.3 to 2.0.0) went out today, for both F22 and F23. It > >removes the ability to edit KeePass 1.x databases, and offers only a > >one-way import to 2.x databases. This breaks anyone depending on the > >ability to sync databases between devices mid-release. > > > >How is this possibly the correct thing to do for users in the middle > >of a release cycle? Could a keepassx2 package not have been pushed > >out, or barring that, a copr for the updated package for people to > >try out on their own if they need it today? Shouldn't breaking > >changes like this wait for release boundaries? (Isn't that why we > >have relatively short release cycles in the first place?) > > I'm concerned by this update too. > > The latest post in Bugzilla says: > > (In reply to Francesco Frassinelli (frafra) from comment #35) > > (In reply to Ed Marshall from comment #33) > > > (and, obviously, send email to the mailing list, so users are > > > actually > > > notified this time rather than getting a surprise breaking upgrade > > > out of > > > the blue) > > > > I can't downgrade keepassx because many people upgraded their > > database > > (comment #34). > > Those people are presumably happy with version 2 (or are stuck with it > now). But there are other people refusing to upgrade because of this. > > A possible solution is to include both keepassx-0.4.4 and > keepassx2-2.0.0 in F22 and F23, so people can choose which version to > use based on their preference (and whether they've already upgraded > their databases). > > > I could provide a keepassx2 subpackage which replaces keepassx = > > 2.0.0, but > > I'm not sure about how to handle Obsoletes/Provides in this case. > > Couldn't both be installed at the same time (if the binaries are > renamed)? You just can't use the same .kdb file with both versions. keepassx 2 uses kdbx file-ending, while keepassx 0.4 uses kdb. I have updated and converted, but the old file is still present and untouched. Jens pgpg23Iywwz41.pgp Description: Digitale Signatur von OpenPGP -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Changes in F24 schedule - two weeks slip
On Tue, Jan 12, 2016 at 03:23:55AM +0100, Jan Kurik wrote: > schedule for 2 weeks. Please check the updated schedule at > https://fedoraproject.org/wiki/Releases/24/Schedule#Key_Milestones . > Dates for the most important milestones follows: Jan, previously when we've updated the schedule, the previous dates for each milestone are retained with a strikethrough (see https://fedoraproject.org/wiki/Releases/23/Schedule). Are we not doing that intentionally this time because we're so early in the process? -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Golang 1.6
On Tue, Jan 12, 2016 at 01:31:30AM +, Peter Robinson wrote: > Will there be an ABI guaranteed beta or RC so that this can be > complete before branching as per the schedule [1]? All major rebases > should be complete prior to branching. > [1] https://fedoraproject.org/wiki/Releases/24/Schedule Since everything is statically linked, the ABI isn't really a factor. It sure would be nice to land before the mass rebuild, though -- otherwise it's a second mini-rebuild of all the Go things. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On Tue, 12.01.16 17:16, Muayyad AlSadi (als...@gmail.com) wrote: > > well. But if you can double fork() in Java you should be fine and can > > it seems that zookeeper is doing the fork in the bash script using nohub > not in java > > > when it finished setting up its listening socket. You cannot script > > typically I loop using "lsof" or "nc" Such sleep loops are ugly and a hack. It would be much better to fix this properly with a clean notification. Doing such sleep loops will just help keeping up java's bad rep for being slow... Also, what happens if the daemon is configured to listen on some different port? Or on multiple ports? Are you parsing the daemon's config file too to figure out what to watch for? YUCK! Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora Rawhide 20160112 compose check report
On Tue, 2016-01-12 at 15:22 +, Fedora compose checker wrote: > Missing expected images: > > Kde disk raw armhfp > > No images in this compose but not Rawhide 20160111 > > No images in Rawhide 20160111 but not this. > > Failed openQA tests: 56 of 64 Looks like either a font rendering change or a GTK+ issue with bolding, I think. I'll look into it and add needles if necessary. I've been meaning to look into the additional failures over the last couple of days, but didn't get to it yet. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unresponsive maintainer procedure for tuxbrewr
On Tue, Jan 12, 2016 at 10:06:40AM -0500, Nico Kadel-Garcia wrote: >> Could we adjust the tooling so that a request for commit access is >> automatically granted if it isn't answered within three months? > That's a potential security problem. If I, for example, can get > commit access to any idle program by claiming it when the original > maintainer is most busy, with no review or doublecheck of my quality > as a new maintainer, I can commit madness on a lot of low maintenance > projects. As I understand it, your sponsor is supposed to look after your commits. > Given so many thousands of Fedora packages, it could get > fascinatingly risky, especially if I start committing intriguing > little '%post' procedures that interfere in subtle ways with other > packages. Yes - there is a risk. But the large number of ignored packages in my mind is the higher security risk. -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
> Polling around a 1s sleep loop. That's a gross hack that's 0.1s On Tue, Jan 12, 2016 at 5:15 PM, Reindl Harald wrote: > > > Am 12.01.2016 um 16:09 schrieb Lennart Poettering: > >> On Tue, 12.01.16 15:57, Reindl Harald (h.rei...@thelounge.net) wrote: >> >> >>> Am 12.01.2016 um 15:45 schrieb Lennart Poettering: >>> On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote: > @Lennart Poettering is there a way to use something like > "ExecStartPost=" > do the the notify with type=simple? > When would you even call that? Somehow your Java app needs to report when it finished setting up its listening socket. You cannot script around that fact >>> >>> at the same point as for mariadb / mysql >>> >> >> ... >> >>> usleep 10 >>> >> ... >> >> Polling around a 1s sleep loop. That's a gross hack >> > > besides that 10 us are hardly a second (the fedora build afaik is > using a sleep 1) it works the last 5 years perfectly and "You cannot script > around that fact" is wrong if you like it or not > > > > > -- > 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
Fedora Rawhide 20160112 compose check report
Missing expected images: Kde disk raw armhfp No images in this compose but not Rawhide 20160111 No images in Rawhide 20160111 but not this. Failed openQA tests: 56 of 64 ID: 2920Test: i386 workstation_live default_install URL: https://openqa.fedoraproject.org/tests/2920 ID: 2919Test: i386 kde_live default_install URL: https://openqa.fedoraproject.org/tests/2919 ID: 2916Test: x86_64 workstation_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/2916 ID: 2915Test: x86_64 workstation_live default_install URL: https://openqa.fedoraproject.org/tests/2915 ID: 2914Test: x86_64 kde_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/2914 ID: 2913Test: x86_64 kde_live default_install URL: https://openqa.fedoraproject.org/tests/2913 ID: 2912Test: i386 generic_boot default_install URL: https://openqa.fedoraproject.org/tests/2912 ID: 2909Test: x86_64 generic_boot default_install@uefi URL: https://openqa.fedoraproject.org/tests/2909 ID: 2908Test: x86_64 generic_boot default_install URL: https://openqa.fedoraproject.org/tests/2908 ID: 2907Test: i386 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/2907 ID: 2906Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/2906 ID: 2905Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/2905 ID: 2904Test: i386 universal server_lvmthin URL: https://openqa.fedoraproject.org/tests/2904 ID: 2903Test: i386 universal server_ext3 URL: https://openqa.fedoraproject.org/tests/2903 ID: 2902Test: i386 universal server_btrfs URL: https://openqa.fedoraproject.org/tests/2902 ID: 2901Test: i386 universal server_software_raid URL: https://openqa.fedoraproject.org/tests/2901 ID: 2900Test: i386 universal server_simple_encrypted URL: https://openqa.fedoraproject.org/tests/2900 ID: 2899Test: i386 universal server_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/2899 ID: 2898Test: i386 universal server_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/2898 ID: 2897Test: i386 universal package_set_minimal URL: https://openqa.fedoraproject.org/tests/2897 ID: 2896Test: x86_64 universal european_language_install URL: https://openqa.fedoraproject.org/tests/2896 ID: 2895Test: x86_64 universal server_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/2895 ID: 2894Test: x86_64 universal server_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/2894 ID: 2893Test: x86_64 universal server_updates_img_local URL: https://openqa.fedoraproject.org/tests/2893 ID: 2892Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/2892 ID: 2890Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/2890 ID: 2887Test: x86_64 universal server_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/2887 ID: 2886Test: x86_64 universal server_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/2886 ID: 2885Test: x86_64 universal server_xfs@uefi URL: https://openqa.fedoraproject.org/tests/2885 ID: 2884Test: x86_64 universal server_ext3@uefi URL: https://openqa.fedoraproject.org/tests/2884 ID: 2883Test: x86_64 universal server_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/2883 ID: 2882Test: x86_64 universal server_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/2882 ID: 2881Test: x86_64 universal server_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/2881 ID: 2880Test: x86_64 universal server_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/2880 ID: 2879Test: x86_64 universal server_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/2879 ID: 2878Test: x86_64 universal server_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/2878 ID: 2877Test: x86_64 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/2877 ID: 2876Test: x86_64 universal server_no_swap URL: https://openqa.fedoraproject.org/tests/2876 ID: 2875Test: x86_64 universal server_lvmthin URL: https://openqa.fedoraproject.org/tests/2875 ID: 2874Test: x86_64 universal server_xfs URL: https://openqa.fedoraproject.org/tests/2874 ID: 2873Test: x86_64 universal server_ext3 URL: https://openqa.fedoraproject.org/tests/2873 ID: 2872Test: x86_64 universal server_btrfs URL: https://openqa.fedoraproject.org/tests/2872 ID: 2871Test: x86_64 universal server_delete_partial URL: https://openqa.fedoraproject.org/tests/2871 ID: 2870Test: x86_64 universal server_software_raid URL: https://openqa.fedoraproject.org/tests/2870 ID: 2869Test: x86_64 universal server_multi_empty URL: https://openqa.fedor
Re: is there a reason for starting zookeeper.service in background?
> well. But if you can double fork() in Java you should be fine and can it seems that zookeeper is doing the fork in the bash script using nohub not in java > when it finished setting up its listening socket. You cannot script typically I loop using "lsof" or "nc" > Polling around a 1s sleep loop. That's a gross hack. usually I use loop i over `seq XYZ` and sleep increasing amount (I start sleep with 0.1s then 0.2s then 0.3 ...) then give up and there is no initial wait bash -c "for i in `seq 1000 10 1000`; do echo '' | nc localhost $PORT 1>/dev/null 2>/dev/null && echo $PORT is up && break; usleep $i; done" > at the same point as for mariadb / mysql thank you this is what I'm talking about On Tue, Jan 12, 2016 at 4:45 PM, Lennart Poettering wrote: > On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote: > > > > > @Lennart Poettering is there a way to use something like "ExecStartPost=" > > do the the notify with type=simple? > > When would you even call that? Somehow your Java app needs to report > when it finished setting up its listening socket. You cannot script > around that fact. > > Lennart > > -- > Lennart Poettering, 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
Re: is there a reason for starting zookeeper.service in background?
Am 12.01.2016 um 16:09 schrieb Lennart Poettering: On Tue, 12.01.16 15:57, Reindl Harald (h.rei...@thelounge.net) wrote: Am 12.01.2016 um 15:45 schrieb Lennart Poettering: On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote: @Lennart Poettering is there a way to use something like "ExecStartPost=" do the the notify with type=simple? When would you even call that? Somehow your Java app needs to report when it finished setting up its listening socket. You cannot script around that fact at the same point as for mariadb / mysql ... usleep 10 ... Polling around a 1s sleep loop. That's a gross hack besides that 10 us are hardly a second (the fedora build afaik is using a sleep 1) it works the last 5 years perfectly and "You cannot script around that fact" is wrong if you like it or not signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On Tue, 12.01.16 15:57, Reindl Harald (h.rei...@thelounge.net) wrote: > > > Am 12.01.2016 um 15:45 schrieb Lennart Poettering: > >On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote: > > > >> > >>@Lennart Poettering is there a way to use something like "ExecStartPost=" > >>do the the notify with type=simple? > > > >When would you even call that? Somehow your Java app needs to report > >when it finished setting up its listening socket. You cannot script > >around that fact > > at the same point as for mariadb / mysql ... > usleep 10 ... Polling around a 1s sleep loop. That's a gross hack. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unresponsive maintainer procedure for tuxbrewr
On Tue, Jan 12, 2016 at 9:31 AM, Sven Lankes wrote: > On Tue, Jan 12, 2016 at 01:30:27PM +0100, Michael Schwendt wrote: > >> Isn't that tedious, inefficient and a waste of time? > > As all of the unresponsive maintainer procedure. > > Could we adjust the tooling so that a request for commit access is > automatically granted if it isn't answered within three months? That's a potential security problem. If I, for example, can get commit access to any idle program by claiming it when the original maintainer is most busy, with no review or doublecheck of my quality as a new maintainer, I can commit madness on a lot of low maintenance projects. Given so many thousands of Fedora packages, it could get fascinatingly risky, especially if I start committing intriguing little '%post' procedures that interfere in subtle ways with other packages. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
Am 12.01.2016 um 15:45 schrieb Lennart Poettering: On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote: @Lennart Poettering is there a way to use something like "ExecStartPost=" do the the notify with type=simple? When would you even call that? Somehow your Java app needs to report when it finished setting up its listening socket. You cannot script around that fact at the same point as for mariadb / mysql [Service] Type=simple User=mysql Group=mysql ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/dev/null ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID _ [root@rh:~]$ cat /usr/libexec/mysqld-wait-ready #!/usr/bin/bash # Service file passes us the daemon's PID daemon_pid="$1" # Wait for the server to come up or for the mysqld process to disappear ret=0 while /usr/bin/true; do RESPONSE=`/usr/bin/mysqladmin --defaults-file=/etc/my.cnf --socket=/var/lib/mysql/mysql.sock --user=UNKNOWN_MYSQL_USER ping 2>&1` mret=$? if [ $mret -eq 0 ]; then break fi # exit codes 1, 11 (EXIT_CANNOT_CONNECT_TO_SERVICE) are expected, # anything else suggests a configuration error if [ $mret -ne 1 -a $mret -ne 11 ]; then ret=1 break fi # "Access denied" also means the server is alive echo "$RESPONSE" | grep -q "Access denied for user" && break # Check process still exists if ! /usr/bin/kill -0 $daemon_pid 2>/dev/null; then ret=1 break fi usleep 10 done exit $ret signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On Tue, 12.01.16 10:22, Muayyad AlSadi (als...@gmail.com) wrote: > > @Lennart Poettering is there a way to use something like "ExecStartPost=" > do the the notify with type=simple? When would you even call that? Somehow your Java app needs to report when it finished setting up its listening socket. You cannot script around that fact. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On Mon, 11.01.16 20:19, Christopher (ctubbsii-fed...@apache.org) wrote: > Hi, > > I'm a co-maintainer for ZooKeeper, and I'd like to help get this right, if > possible. More importantly, I'm interested in setting a precedent for Java > system services in systemd. So, forgive my ignorance, but what exactly is > the generally recommended way of launching Java-based applications as > system services in systemd? Is there a good model to follow? A Java service > that gets this right? I am not a Java programmer, so I don't really know how Java works that well. But if you can double fork() in Java you should be fine and can implement correct Type=forking (i.e. SysV) semantics, but I have the suspicion that Java doesn't really permit the concept of fork()... Alternatively, you could implement Type=notify semantics, i.e implement in Java the equivalent of sd_notify(). It's trivial actually, you just send a single AF_UNIX/SOCK_DGRAM datagram with a newline separated string to the socket specified in $NOTIFY_SOCKET. See the NOTES section in sd_notify(3) about this. That said, I have the suspicion that Java might not allow you to use AF_UNIX/SOCK_DGRAM sockets, either? If that's the case, then you could add a trivial JNI wrapper around the C routine that is sd_notify(), and get Type=notify semantics that way... I think there's also this: https://commons.apache.org/proper/commons-daemon/ Not sure how current this is, but it might get you Type=forking semantics too. But I have no idea what this really does, it could be that it's not actually really implementing proper UNIX semantics... > Also, as I understand it, Java processes don't really fork in any way > that's useful here. The JVM has it's own internal threading model. So, > what's the best way for them to play nice with systemd? Should they all be > simple? Or should they all be launched by a shell script which implements > the double-forking paradigm? If the latter, wouldn't that add a lot of > complication that systemd is designed to eliminate with the simplicity of > writing units? You cannot really implement the double-forking concept with shell scripts only. Also, and most importantly you really need some kind of notification concept to indicate completion of initialization. That can either be sd_notify() for Type=notify mode, or something internal+exit() in the parent for Type=forking mode, but it must be something. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Bug 1297769] perl-Code-TidyAll-0.38 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1297769 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Code-TidyAll-0.38-1.fc ||24 Resolution|--- |RAWHIDE Last Closed||2016-01-12 09:43:36 --- Comment #1 from Petr Pisar --- An enhancement release suitable for Fedora >= 24. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org
Re: Unresponsive maintainer procedure for tuxbrewr
On Tue, Jan 12, 2016 at 01:30:27PM +0100, Michael Schwendt wrote: > Isn't that tedious, inefficient and a waste of time? As all of the unresponsive maintainer procedure. Could we adjust the tooling so that a request for commit access is automatically granted if it isn't answered within three months? -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Changes in F24 schedule - two weeks slip
On Tue, Jan 12, 2016 at 09:02:08AM -0500, Josh Boyer wrote: > On Tue, Jan 12, 2016 at 8:58 AM, David Howells wrote: > > Jan Kurik wrote: > > > >> let me inform you about changes in Fedora 24 schedule. > >> > >> There is a will to accommodate GCC6 compiler in F24 and use it to > >> compile all the binaries delivered in this release [1]. > > > > Do the cross-gcc packages also need moving to GCC6 immediately as I believe > > It would be a good idea regardless... > > > they're used to compile some bits too? > > Which bits? AFAIK, Fedora does not allow cross-compiling for official > Fedora packages. They're used to build some firmware blobs for QEMU/KVM, eg seabios because we need to build x86 seabios code on ppc/arm/etc hosts for example. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] Fedora 24 Rawhide 20160112 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 24 Rawhide 20160112. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pykickstart - 20160109: 2.22-1, 20160112: 2.24-1 Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/24 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160112_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160112_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160112_Base https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160112_Server https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160112_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160112_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160112_Security_Lab https://fedoraproject.org/wiki/Template:Fedora_24_Rawhide_20160112_Download Thank you for testing! -- Mail generated by relval: https://www.happyassassin.net/wikitcms/ On behalf of: adamwill ___ test-announce mailing list test-annou...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Changes in F24 schedule - two weeks slip
On Tue, Jan 12, 2016 at 9:02 AM, Josh Boyer wrote: > On Tue, Jan 12, 2016 at 8:58 AM, David Howells > wrote: > > Jan Kurik wrote: > > > >> let me inform you about changes in Fedora 24 schedule. > >> > >> There is a will to accommodate GCC6 compiler in F24 and use it to > >> compile all the binaries delivered in this release [1]. > > > > Do the cross-gcc packages also need moving to GCC6 immediately as I > believe > > It would be a good idea regardless... > > > they're used to compile some bits too? > > Which bits? AFAIK, Fedora does not allow cross-compiling for official > Fedora packages. > > josh > > We do, as our mingw packages are all cross compiled packages. -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Build root prepared by DNF is way larger
Dne 18.8.2015 v 16:26 Vít Ondruch napsal(a): > Hi all, > > Today, I noticed that mock build root prepared by DNF is significantly > larger then prepared by YUM (see attached logs). Owners of packages > installed into minimal buildroot probably wants to review their > dependency chain. > > I also reported the issue against DNF [1] in case DNF guys wants to > improve this situation. > > > Vít > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1254634 > This change does not look to be reflected on Koji, so I opened https://fedorahosted.org/rel-eng/ticket/6330 Vít -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Changes in F24 schedule - two weeks slip
On Tue, Jan 12, 2016 at 8:58 AM, David Howells wrote: > Jan Kurik wrote: > >> let me inform you about changes in Fedora 24 schedule. >> >> There is a will to accommodate GCC6 compiler in F24 and use it to >> compile all the binaries delivered in this release [1]. > > Do the cross-gcc packages also need moving to GCC6 immediately as I believe It would be a good idea regardless... > they're used to compile some bits too? Which bits? AFAIK, Fedora does not allow cross-compiling for official Fedora packages. josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Changes in F24 schedule - two weeks slip
Jan Kurik wrote: > let me inform you about changes in Fedora 24 schedule. > > There is a will to accommodate GCC6 compiler in F24 and use it to > compile all the binaries delivered in this release [1]. Do the cross-gcc packages also need moving to GCC6 immediately as I believe they're used to compile some bits too? David -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
upstream issue < https://issues.apache.org/jira/browse/ZOOKEEPER-2095
suggests the following
ExecStart=/usr/bin/java \
-Dzookeeper.log.dir=/var/log/zookeeper \
-Dzookeeper.root.logger=INFO,ROLLINGFILE \
-cp /usr/share/java/zookeeper/* \
-Dlog4j.configuration=file:/etc/zookeeper/log4j.properties \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.local.only=false \
org.apache.zookeeper.server.quorum.QuorumPeerMain \
/etc/zookeeper/zoo.cfg
and it's seems that this is accepted in their SVN (against trunk revision
1685685)
On Tue, Jan 12, 2016 at 2:44 PM, Muayyad AlSadi wrote:
> > - If the socket availability doesn't matter, remove the nohup,
> redirection, fork stuff and use a "Type = simple" service. Presuming that
> the java process runs in foreground this should be fine.
>
> passing -f to solr or start-foreground to zookeeper would short-circuit
> the "nohup" as it would use "exec java blah blah" like this
>
> start-foreground)
> ZOO_CMD=(exec "$JAVA")
> "${ZOO_CMD[@]}" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
> "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
>
> which is my preferred way
>
> > - If the java process runs in background anyway,
>
> no it's not. ZK's java process is a foreground process
>
> > - If you need to socket(s) to be available and type = forking doesn't
> make it (exits parent to early, doesn't fork) the code should be fixed by
> teaching it to issue a sd_notify (-> Type = notify).
>
> can we do this using some "side" command like "ExecStartPost="
>
>
>
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: keepassx 2.0?
On Tue, 2016-01-12 at 10:42 +, Jonathan Wakely wrote: > P.S. the people who want version 2 already had *several* COPRs to > choose from that provide version 2. Pushing it to the stable releases > was really not necessary. Seems to be hitting users too: https://ask.fedoraproject.org/en/question/81225/upgrade-to-keepassx-20- from-keepassx-04-unable-to-open-database/ -- Thanks, Regards, Ankur Sinha "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
> - If the socket availability doesn't matter, remove the nohup,
redirection, fork stuff and use a "Type = simple" service. Presuming that
the java process runs in foreground this should be fine.
passing -f to solr or start-foreground to zookeeper would short-circuit the
"nohup" as it would use "exec java blah blah" like this
start-foreground)
ZOO_CMD=(exec "$JAVA")
"${ZOO_CMD[@]}" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
which is my preferred way
> - If the java process runs in background anyway,
no it's not. ZK's java process is a foreground process
> - If you need to socket(s) to be available and type = forking doesn't
make it (exits parent to early, doesn't fork) the code should be fixed by
teaching it to issue a sd_notify (-> Type = notify).
can we do this using some "side" command like "ExecStartPost="
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Stop please
On Tue, 12 Jan 2016 00:26:14 +, Andrew Clayton wrote: > Interesting. In Claws Mail for this message I'm seeing > > From: > To: > Subject: > Date: > X-Mailer: > Organization: > Message-ID: > > (true, they may not all be shown by default) Preferences > Message View > Text Options > Headers Claws Mail can be adjusted quite a lot in that area. Ctrl+H to show all headers. Various other mail programs also at least displays a few headers, such as Subject, Date, To and From. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unresponsive maintainer procedure for tuxbrewr
On Tue, 12 Jan 2016 11:17:37 +0100, Christian Dersch wrote: > > The same procedure has been started a few times, at least > > > > https://bugzilla.redhat.com/736874 > > https://bugzilla.redhat.com/963890 > > > > Requesting co-maintainer access would be a way to solve such > > isues. > > > I requested it in pkgdb some weeks ago. Got no response, thats why I > started the unresponsive maintainer procedure. Isn't that tedious, inefficient and a waste of time? Having to start the non-responsive maintainer procedure again and again just to get a response (hopefully)? How long have the packages been unmaintained this time? Why protect the package from getting a few co-maintainers? Would help not be welcome in this case? Would FESCo insist on waiting for the procedure to be completed instead of granting an exception? https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Exception_procedure Now I dunno whether you would be happy with a belated response from the maintainer, but something obviously doesn't work well here. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
On 12/24/2015 10:01 PM, Jason L Tibbitts III wrote: To satisfy my curiosity, I grepped the convenient tarball of specfiles (http://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz) for lines matching "(?After fixing %define -> %global in my spec file, my vim is having several problems: * First of them is missing syntax highlight for %define macro - bug from 2014 [1]. Patch fixes it. * Second is c sequence for generating changelog record stopped working. Reported as [2] with local patch. CCing vim maintainer. Can we have it in F23? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1058041 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1297746 Greetings, -- Jakub Jelen Security Technologies Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On 12/01/16 10:54, Muayyad AlSadi wrote:
the problem here is the bash script wrapped around
in the good old days of solr there used a param passed to solr.jar to
make the fork magic in java (maybe it was --daemon)
but now it's done in bash with "nohup" followed by "while true lsof
-PniTCP:$SOLR_PORT -sTCP:LISTEN" to detect if it's up before exit
This script, right?
nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null
&
if [ $? -eq 0 ]
Now, this script
- Runs the process using nohup
- Merges stderr with stdout
- Forks directly on start.
- Uses a bash parent as pid.
Nothing of this makes systemd's task simpler. Personally, I'd consider
three routes:
- If the socket availability doesn't matter, remove the nohup,
redirection, fork stuff and use a "Type = simple" service. Presuming
that the java process runs in foreground this should be fine.
- If the java process runs in background anyway, it could be fixed by
teaching it to write a pidfile (-> Type = forking). This should be a
simple fix which could be upstreamed.
- If you need to socket(s) to be available and type = forking doesn't
make it (exits parent to early, doesn't fork) the code should be fixed
by teaching it to issue a sd_notify (-> Type = notify).
Just my 5 öre.
Cheers!
--alec
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
evolution-data-server soname version bump in rawhide the next week
Hi, the 3.19.4 release of evolution-data-server changes soname version for camel, due to some API changes. I will rebuild packages for which I have commit rights, the same as I can help with the API change fixes, thus feel free to ping me or drop an e-mail. I do not think that other than Evolution will need more attention, others might be rebuild just to be sure nothing broke. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
rawhide report: 20160112 changes
Compose started at Tue Jan 12 05:15:02 UTC 2016 Broken deps for i386 -- [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [OpenColorIO] OpenColorIO-tools-1.0.9-8.fc23.i686 requires libOpenImageIO.so.1.5 [alliance] alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2 [consul] golang-github-hashicorp-consul-devel-0-0.1.git5079177.fc24.noarch requires golang(github.com/armon/circbuf) [eclipse-jbosstools] eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires osgi(org.eclipse.tm.terminal) [fawkes] fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 [gcc-python-plugin] gcc-python2-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 gcc-python2-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 gcc-python3-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 gcc-python3-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 [gnash] 1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 [golang-github-hashicorp-serf] golang-github-hashicorp-serf-devel-0-0.3.git4bd6183.fc24.noarch requires golang(github.com/armon/circbuf) [golang-github-kraman-libcontainer] golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch requires golang(github.com/docker/docker/pkg/netlink) [golang-github-kubernetes-heapster] golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/info/v1) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/client) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/schema)
Re: Automatically generating needed requires for julia
On 01/12/2016 09:58 AM, Mikolaj Izdebski wrote:
On 01/11/2016 11:48 PM, Orion Poplawski wrote:
The julia language loads libraries at run time by using the .so filename. We
work around this in the julia package by symlinking the needed sonames into
%{_libdir}/julia/, e.g.:
for lib in arpack cholmod dSFMT git2 fftw3_threads gmp mprf openlibm
openspecfun pcr2-8 umfpack
do
soname=$(objdump -p %{_libdir}/lib${lib}.so | awk '$1 == "SONAME" { print
$2}')
ln -s ../${soname} %{buildroot}%{_libdir}/julia/lib${lib}.so
done
Now we want to automatically generate the needed rpm requires, e.g.:
libarpack.so.2()(64bit)
What I came up with is a rpm-julia-hooks package that julia would BR that
would use rpm fileattrs to generate these. This feels a bit klunky having a
separate package just to do this task.
Does anyone else have any ideas?
Looks like you are trying to use a custom dependency generator in
addition to internal one. If it's for use in a single package then the
following solution should work:
%global _use_internal_dependency_generator 0
%global __find_requires %{SOURCE666} %{_rpmconfigdir}/find-requires
Source666: %{name}-find-requires.sh
Where julia-find-requires.sh should be a script that generates custom
requires (prints them to stdout) and then calls internal RPM dependency
generator (passed as $1).
Please dont. Disabling internal dependency generator is a trick from
last decade which has unwanted side-effects and basically should never
be needed or used these days.
Generally speaking putting the fileattrs into a package of their own is
the right thing to do, but can indeed be a bit klunky if its for a
single package only.
I wouldn't necessarily recommend this, but you *can* wrap just the ELF
dependency generator similarly to the above global find-requires trick, eg
Source111: julia-requires.sh
%global __elf_requires %{SOURCE111}
...and then in julia-requires.sh, call the normal elfdeps generator (for
added bonus, save the original %__elf_requires macro someplace and use
that) and in addition do your own thing for files in %{_libdir}/julia/.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: keepassx 2.0?
On 12/01/16 10:41 +, Jonathan Wakely wrote: On 12/01/16 01:47 -0800, Ed Marshall wrote: Bringing this discussion to the mailing list, since it's all apparently happened in bugzilla until now (and I only found out when I updated this evening). For reference: https://bugzilla.redhat.com/show_bug.cgi?id=1282825 This update (0.4.3 to 2.0.0) went out today, for both F22 and F23. It removes the ability to edit KeePass 1.x databases, and offers only a one-way import to 2.x databases. This breaks anyone depending on the ability to sync databases between devices mid-release. How is this possibly the correct thing to do for users in the middle of a release cycle? Could a keepassx2 package not have been pushed out, or barring that, a copr for the updated package for people to try out on their own if they need it today? Shouldn't breaking changes like this wait for release boundaries? (Isn't that why we have relatively short release cycles in the first place?) I'm concerned by this update too. The latest post in Bugzilla says: (In reply to Francesco Frassinelli (frafra) from comment #35) (In reply to Ed Marshall from comment #33) (and, obviously, send email to the mailing list, so users are actually notified this time rather than getting a surprise breaking upgrade out of the blue) I can't downgrade keepassx because many people upgraded their database (comment #34). Those people are presumably happy with version 2 (or are stuck with it now). But there are other people refusing to upgrade because of this. A possible solution is to include both keepassx-0.4.4 and keepassx2-2.0.0 in F22 and F23, so people can choose which version to use based on their preference (and whether they've already upgraded their databases). I could provide a keepassx2 subpackage which replaces keepassx = 2.0.0, but I'm not sure about how to handle Obsoletes/Provides in this case. Couldn't both be installed at the same time (if the binaries are renamed)? You just can't use the same .kdb file with both versions. P.S. the people who want version 2 already had *several* COPRs to choose from that provide version 2. Pushing it to the stable releases was really not necessary. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: keepassx 2.0?
On 12/01/16 01:47 -0800, Ed Marshall wrote: Bringing this discussion to the mailing list, since it's all apparently happened in bugzilla until now (and I only found out when I updated this evening). For reference: https://bugzilla.redhat.com/show_bug.cgi?id=1282825 This update (0.4.3 to 2.0.0) went out today, for both F22 and F23. It removes the ability to edit KeePass 1.x databases, and offers only a one-way import to 2.x databases. This breaks anyone depending on the ability to sync databases between devices mid-release. How is this possibly the correct thing to do for users in the middle of a release cycle? Could a keepassx2 package not have been pushed out, or barring that, a copr for the updated package for people to try out on their own if they need it today? Shouldn't breaking changes like this wait for release boundaries? (Isn't that why we have relatively short release cycles in the first place?) I'm concerned by this update too. The latest post in Bugzilla says: (In reply to Francesco Frassinelli (frafra) from comment #35) (In reply to Ed Marshall from comment #33) > (and, obviously, send email to the mailing list, so users are > actually > notified this time rather than getting a surprise breaking upgrade > out of > the blue) I can't downgrade keepassx because many people upgraded their database (comment #34). Those people are presumably happy with version 2 (or are stuck with it now). But there are other people refusing to upgrade because of this. A possible solution is to include both keepassx-0.4.4 and keepassx2-2.0.0 in F22 and F23, so people can choose which version to use based on their preference (and whether they've already upgraded their databases). I could provide a keepassx2 subpackage which replaces keepassx = 2.0.0, but I'm not sure about how to handle Obsoletes/Provides in this case. Couldn't both be installed at the same time (if the binaries are renamed)? You just can't use the same .kdb file with both versions. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unresponsive maintainer procedure for tuxbrewr
On 01/12/2016 10:00 AM, Michael Schwendt wrote: > The same procedure has been started a few times, at least > > https://bugzilla.redhat.com/736874 > https://bugzilla.redhat.com/963890 > > Requesting co-maintainer access would be a way to solve such > isues. > -- > I requested it in pkgdb some weeks ago. Got no response, thats why I started the unresponsive maintainer procedure. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unable to push into memtest86+/master
- Original Message - > > > - Original Message - > > On Fri, 8 Jan 2016 11:12:37 -0500 (EST) > > Jaroslav Skarvada wrote: > > > > > $ git push -v > > > Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+ > > > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > > > FATAL: W any memtest86+ jskarvad DENIED by fallthru > > > (or you mis-spelled the reponame) > > > fatal: Could not read from remote repository. > > > > > > Please make sure you have the correct access rights > > > and the repository exists. > > > > > > Apparently I have the correct rights: > > > https://admin.fedoraproject.org/pkgdb/package/rpms/memtest86+/ > > > > > > Any idea what's wrong? > > > > Odd. The rights look correct also in gitolite. ;( > > > > At least right now. Can you try pushing again and confirm it's still > > broken? > > > > kevin > > > Hi Kevin, it's still broken for me. I tried to do fresh checkout (this time > with pure git, no fedpkg front-end): > > $ git clone 'ssh://jskar...@pkgs.fedoraproject.org/memtest86+' > Cloning into 'memtest86+'... > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > remote: Counting objects: 573, done. > remote: Compressing objects: 100% (342/342), done. > remote: Total 573 (delta 275), reused 458 (delta 207) > Receiving objects: 100% (573/573), 241.70 KiB | 0 bytes/s, done. > Resolving deltas: 100% (275/275), done. > Checking connectivity... done. > > Then I updated SPEC file and tried to push the changes: > > $ git push > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > FATAL: W any memtest86+ jskarvad DENIED by fallthru > (or you mis-spelled the reponame) > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > I tried to push into 'grep/master' and it worked. So It seems that only > the memtest86+ is broken for me. It is really weird as I am proven packager > so it shouldn't complain about ACLs > > thanks & regards > > Jaroslav > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > Created ticket: https://fedorahosted.org/fedora-infrastructure/ticket/5058 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
> the problem here is the bash script wrapped around in the good old days of solr there used a param passed to solr.jar to make the fork magic in java (maybe it was --daemon) but now it's done in bash with "nohup" followed by "while true lsof -PniTCP:$SOLR_PORT -sTCP:LISTEN" to detect if it's up before exit the zookeeper bash script does not have such lsof check and I tried to make it print usage Usage: ZooKeeperServerMain configfile | port datadir [ticktime] [maxcnxns] no daemon-related option so the best choice IMHO is to short-circuit all the bash forking On Tue, Jan 12, 2016 at 11:34 AM, Muayyad AlSadi wrote: > > the problem here is the bash script wrapped around > > just pass "start-foreground" and it will be short-circuit > > > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
keepassx 2.0?
Bringing this discussion to the mailing list, since it's all apparently happened in bugzilla until now (and I only found out when I updated this evening). For reference: https://bugzilla.redhat.com/show_bug.cgi?id=1282825 This update (0.4.3 to 2.0.0) went out today, for both F22 and F23. It removes the ability to edit KeePass 1.x databases, and offers only a one-way import to 2.x databases. This breaks anyone depending on the ability to sync databases between devices mid-release. How is this possibly the correct thing to do for users in the middle of a release cycle? Could a keepassx2 package not have been pushed out, or barring that, a copr for the updated package for people to try out on their own if they need it today? Shouldn't breaking changes like this wait for release boundaries? (Isn't that why we have relatively short release cycles in the first place?) -- Ed Marshall Felix qui potuit rerum cognoscere causas. http://esm.logic.net/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
> the problem here is the bash script wrapped around just pass "start-foreground" and it will be short-circuit -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
Am 12.01.2016 um 09:22 schrieb Muayyad AlSadi:
nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT"
2>&1 < /dev/null &
if [ $? -eq 0 ]
...
/bin/echo -n $! > "$ZOOPIDFILE"
so I believe the forking is done by bash without a ready socket.
@Reindl.Harald the above bash is doing the fork, without any listening
socket. so it's not guessing
the problem here is the bash script wrapped around
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unresponsive maintainer procedure for tuxbrewr
On Mon, 11 Jan 2016 21:48:25 +0100, Christian Dersch wrote: > Hi all, > > I tried to contact tuxbrewr some weeks ago (due to quassel bug fixes and > maintainance), without any response. Does anybody know how to contact > him? I already tried smparr...@gmail.com without success. > > Info: https://bugzilla.redhat.com/show_bug.cgi?id=1294472 The same procedure has been started a few times, at least https://bugzilla.redhat.com/736874 https://bugzilla.redhat.com/963890 Requesting co-maintainer access would be a way to solve such isues. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
>> my point is that having a child double forked does not mean Zookeeper TCP
>> port is ready which is as bad as simple which is also does not indicate
>> when it's ready
> Well, then Zookeeper is simply broken.
sorry it's just me. I forget that the classic UNIX double fork do listen
before the double fork not after it.
I'm sorry again it would be for sure ready when the inner child is forked
if it was done the classical UNIX way (but it seems not, it's done by bash
see below)
but anyway. let's discuss how it should be done properly.
> recommended way of launching Java-based applications as system services
in systemd?
usually I love to pass -f to solr and I was considering passing "
start-foreground" to make it foreground
because I don't have enough knowledge/trust in their bash scripts (and life
is to short to read them and review them)
so I just short-circuit all background and process management and make
systemd care about that.
this is "my way" not "the recommended way".
and of course I would love hear from people like you "the right way".
for example do they have a monitoring sub-process (to do auto restart)? how
do they handle reload or restart ..etc?
if someone run the bash script directly telling it to restart what would
happen ...etc.
all this is eliminated. I don't really care when solr is actually ready
because my web application does not need solr to start (refresh page would
work)
> Or should they all be launched by a shell script which implements the
double-forking paradigm?
> is that just guessing or proven?
I used to believe that the double forking is done by java (after the socket
is listening to requests) not bash.
but the bash script contains lines like this
nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1
< /dev/null &
if [ $? -eq 0 ]
...
/bin/echo -n $! > "$ZOOPIDFILE"
so I believe the forking is done by bash without a ready socket.
@Reindl.Harald the above bash is doing the fork, without any listening
socket. so it's not guessing.
if you are like me don't really care about the exact time the socket is
ready just foreground with type=simple
if you do care about that either in the part that need it use nc magic
for i in `seq 9`; do echo "" | nc localhost $PORT 1>/dev/null 2>/dev/null
&& echo "$PORT is up" && break; sleep 0.$i; done
you can wrap it in /bin/bash -c "" if you need an absolute path.
> What about a simple JNI wrapper to sd_notify(3)? Shouldn't be hard, gives
the process a chance to actually signal when its' ready.
you can use "systemd-notify" in the bash script above just before "&& break"
but I would still go with foreground.
@Lennart Poettering is there a way to use something like "ExecStartPost="
do the the notify with type=simple?
On Mon, Jan 11, 2016 at 10:59 PM, Alec Leamas wrote:
> On 11/01/16 21:19, Christopher wrote:
>
> I'm a co-maintainer for ZooKeeper, and I'd like to help get this right,
>> if possible. More importantly, I'm interested in setting a precedent for
>> Java system services in systemd. So, forgive my ignorance, but what
>> exactly is the generally recommended way of launching Java-based
>> applications as system services in systemd? Is there a good model to
>> follow? A Java service that gets this right?
>>
>> Also, as I understand it, Java processes don't really fork in any way
>> that's useful here. The JVM has it's own internal threading model. So,
>> what's the best way for them to play nice with systemd? Should they all
>> be simple? Or should they all be launched by a shell script which
>> implements the double-forking paradigm? If the latter, wouldn't that add
>> a lot of complication that systemd is designed to eliminate with the
>> simplicity of writing units?
>>
>>
> What about a simple JNI wrapper to sd_notify(3)? Shouldn't be hard, gives
> the process a chance to actually signal when its' ready.
>
> Cheers!
>
> --alec
>
> --
>> 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
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Packaging of PlayOnLinux
On Sat, 2016-01-09 at 23:36 -0600, Bruno Wolff III wrote: > On Mon, Jan 04, 2016 at 10:33:01 +0100, > Jiří Konečný wrote: > > On Fri, 2015-12-11 at 10:44 +0100, Jiří Konečný wrote: > > > Hello all, > > > > > > it was some time but I finally made it to the Fedora review > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1290513 > > > > > > This is my first package so I need a sponsor. Could anyone please > > > look > > > on this. I will gladly take any help you can give me. > > Hans was looking to do a review swap for a shooter game not too long > ago. Thank you for telling me this but I don't thing that I as a new packager have enough experience to do review of another package. I'm going to look on his package if I find there something wrong but I'm mostly learning how to create package properly now. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
