wish to resurrect shorewall on EPEL 6 (and re-self-introduction)
by J. Randall Owens
As I previously wrote (v.i.), I'd like to un-retire shorewall for EPEL
6. It seems as though the only reason for its retirement is that the
previous maintainer hadn't updated it in four years, presumably having
lost interest in it. I've had shorewall-4.5.4 & -4.4.17 building in my
personal repo for a while now, and in use on my servers, so it doesn't
seem there's any build problem that precludes it from (EP)EL6.
If there's no objection, I'll file the releng ticket. If there's a
simple shortcut in git for reverting the dead.package file to the
shorewall.spec etc., I'd appreciate knowing it; otherwise, I'll muddle
through the git checkout/push somehow, I suppose.
And since it's been a long time since I introduced myself, without my
contributing much since then, it can serve as a bit of a
re-introduction, as well.
-------- Forwarded Message --------
To: Michele Baldessari <michele [AT] acksyn [DOT] org>
From: J. Randall Owens <jrowens.fedora(a)ghiapet.net>
Subject: wish to resurrect shorewall on EPEL 6
Date: Sat, 15 Jul 2017 01:26:46 +0100
Hello. I've been a mostly-quiet Fedora user and occasional minor
contributor for a fair while now, certainly over a decade (and RHL
before that), and I love my shorewall, and I have a few CentOS 6 servers
to tend to. Some of these being new to me, I found that they already had
shorewall & shorewall-core on them, so I went to add shorewall6 to the
mix, and after some puzzled moments, realised that it was all gone from
the EPEL repository. So, I'd like to bring it back for EPEL 6, and
figured I should run it past you first, see if there was a particular
reason for retiring it, or if it was just that you didn't have the
interest in 6 in particular.
I've already been in the Fedora CLA, Git Commit, etc. groups for a while
now [1], after I had some plans for packages that never materialised.
Most recently, I took on gogoc (also networking- & IPv6-related) in a
hurry before it would be automatically retired, only to discover that
the tunnel service it was intended to connect to was going defunct, so
not much point to keeping it afloat. A couple of other packages, though,
I had good intentions for, but just never got the hang of how to go
through the right combination of bodhi, koji, pkgdb, pungi, plague,
copr, or whatever else for Fedora/EPEL. So if you're willing to let me
take on EPEL 6, and walk me through a build or two so I can see how it's
done (and take notes), that would be wonderful.
I've had my own repository of a handful of packages since Fedora 9 [2],
basically just for my own use, so I know the packaging side of things
pretty well, and using mock. And I know a bit of git, somewhat narrowly,
but reasonably well. Using branches is a weak area for me; I haven't
done that much yet, and as I understand it, I think that might be
important for this, although I guess there's just a branch per
Fedora/EPEL release, and there isn't further branching after that,
right? I seem to see that there were tags per version up through 4.4.10,
and then they stopped, and I don't know if that was due to a policy
change, or just personal preference of a (possibly new) maintainer.
Anyway, if you're willing, we can sort that out later.
If we can do this, I expect we should keep it at 4.x, and not make the
jump to 5.x, this being EPEL. Any opinion on whether 4.6.y would be
reasonable? Looks like the last one was 4.5.4, so could go either 4.5.21
or 4.6.13, if playing it safe. If you don't have an opinion yet, I can
look into the 4.6 changes and see whether it's likely to negatively
affect existing installations.
Thank you for your time, and for keeping the Fedora and EPEL 7 branches
of shorewall alive (which I also use, on the home machines).
[1] https://admin.fedoraproject.org/accounts/user/view/jrowens
[2] http://download.ghiapet.net/pub/ghiapet/linux/
--
J. Randall Owens | http://www.GhiaPet.net/
6 years, 3 months
Packaging DSO symlinks
by Igor Gnatenko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
You might have seen that we are trying to eliminate /sbin/ldconfig from
scriptlets which would speedup installation / upgrade of packages
**significantly**.
One of cases Florian brought that in case of libcrypt/libcrypt-nss, libraries
didn't have symlinks, so if it would not call ldconfig in its scriptlet, then
any packages which depend on libcrypt.so would fail to execute.
In 99% (this number came just out of my head, not a real investigation) of
packages, we always package those symlinks.
So I'm going to push change to glibc which during build process executes
ldconfig in buildroot which is forcing to create those symlinks and your
package would fail to build with something like:
error: Installed (but unpackaged) file(s) found:
/usr/lib64/libhello.so.1
To disable this you would need to use `%undefine __brp_ldconfig` and you really
need to make sure that you have %post/%postun scriptlets with /sbin/ldconfig.
The plan is to get this in, then get transfiletrigger in glibc which would
execute ldconfig just **once per transaction** and then start removing
scriptlets from packages.
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpvOYgACgkQaVcUvRu8
X0y2dg//XN5KrnjG05+imdYHemsbGj0lX4CbEIjJiZMQ4Y35M/qtgSE4GhhQjqrv
+atrlzE8iV7oszMxbn3m59BHCmC0XGDn1Z68nc0WECTd3wfURt5/WLJiYCtxaDtL
Jai27G1I2orFO6s+jPr6Vi4FFFvaMKlSNlcXEFRCp2UOC+OLnIqPr5UueOAy6hk0
GUeiMto7VE0Nq/ScKfXQG70tJcdUB9MFkrBI3duhwCCNWqKdeSKDV37ZrDpCO98O
8OzoZhx22FcSvIodYNIz4FPYzRVUDegP4AwbRaeEq6JVhGMY6GrhQ/lFPvMQNynp
C2+t4U7hKXRut0GlOwPbyD0NxWy0rOMdz2lAyzOQIZZUcKmo0gvMxnYWDrPY8X1W
5uCdgMqvez3cXTj7crUBu2/jkJIeTG5INdgePZeDf6mX8Y1yp0IwP3WqeiQSLggN
HV/6bjNX4yLSPAtWoxZyQtwADl6LEW9oVqJB1nLdk2URx0hnN7Sl3e7xl6RLbHR6
PNXXku3Y2HtuFhe7HWb3TyBK1gpOz/GK7+Hqycd2BCozNnXc3Ho4wTe+YXip/xGL
KW1vJty0BXvgYXuDUFB/sO4ETWvDMVQMMLYxnjcHIo74VxCYlKAbLP40efQkh3wq
Zcol+j6TbqdA6aKBfO03nt5Q17P0+8BewfXNvcP3meeSMcxl470=
=k+H3
-----END PGP SIGNATURE-----
6 years, 3 months
kernel component on bugzilla and call for "old bugs hunting season"
to pen
by Tomasz Kłoczko
Hi,
In last two years, I've created something between 10 to 20 tickets against
the kernel.
Today after reboot on latest rc9 I found OOPS in dmesg and as usually, my
first thought was "raise the ticket". Just after this was second one ..
"but none of my kernel tickets has been replied or even closed as DUP!!".
So I've done some search on Bugzilla for kernel tickets in NEW state.
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&component=kernel&l...
Above shows list of current kernel tickets in NEW state with older tickets
on top.
There are 691 such tickets and older is from 2009.
It would be good to clean this mess because in current state opening any
new tickets do not make to much sense.
I'm asking for helping anyone who has Bugzilla account.
It would be good to start "bugs hunting season" to close as much as
possible already outdated tickets.
All Fedora NEW tickets sorted from oldest as first is possible to display
by going to URL:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&list_id=8346395&or...
There is now not closed and in NEW state *14474* such tickets.
1) Probably it would be good start posting one time a week summary stats
about Bugzilla tickets. Any volunteer to create such weekly report?
2) Q: do we need new kernel package maintainer or secondary co maintainers?
3) can someone crate stats highest flow of the tickets in Bugzilla per
package to find a help for some packages maintainers?
kloczek
PS. Please do not send comments why it happened or who can be blamed
personally for this.
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
6 years, 3 months
[heads-up] soname version bump for evolution-data-server in rawhide
by Milan Crha
Hello,
the next week release (2018-02-05) of evolution-data-server,
version 3.27.90, will contain a soname version bump of libcamel,
libedataserver and libedataserverui. It contains some backward
incompatible changes, though I expect minimal impact on other packages,
because that API was more or less related to evolution itself only.
That means that a simple rebuild of affected packages should be enough,
but in case of any issue feel free to ask me for help.
The list of dependencies according to:
# dnf repoquery --whatrequires evolution-data-server-devel --alldeps
follows:
evolution
folks
maya-calendar
but it seems surprisingly low number of packages, because I know of
several others (like syncevolution, evolution-ews, evolution-mapi, ...)
which also depend of evolution-data-server.
I'll rebuild packages I've commit rights for myself, unless the main
maintainer(s) will be quicker.
Bye,
Milan
6 years, 3 months
[Test-Announce] 2018-01-29 @ 16:00 UTC - Fedora QA Meeting
by Adam Williamson
# Fedora Quality Assurance Meeting
# Date: 2018-01-29
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net
Greetings testers!
Apologies for the late notice, but we haven't met for a few weeks, so I
thought we could do the meeting tomorrow - there's a few topics we
could talk about.
If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.
== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Fedora 28 mass rebuild
3. Update gating (and other gating)
4. Wiki to docs migration
5. Open floor
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
_______________________________________________
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org
6 years, 3 months
libvpx 1.7.0 update in rawhide
by Tom Callaway
The new libvpx 1.7.0 update in rawhide bumped SOVER because of an ABI
break. I rebuilt all the dependent packages I could find with dnf
repoquery, except for firefox and thunderbird due to lack of access.
Apologies if I missed something.
~tom
P.S. I will not be pushing libvpx 1.7.0 into any stable Fedora releases.
6 years, 3 months
