Here are the recent changes to the packaging guidelines.
-
The guidelines were updated to reflect the current policy that Fedora
packages are no longer permitted to carry SysV-style initscripts. The
relevant guidelines page has been moved to the EPEL hierarchy.
* https://fedoraproject.org/w
> "IG" == Igor Gnatenko writes:
IG> How do I proceed with it? I think I can name it ANTs in upper case,
IG> but probably it will confuse people. Suggestions? Ideas?
"Package names should be in lower case and use dashes in preference to
underscores."
-- https://fedoraproject.org/wiki/Packag
I also sent a notice to Fedora's python list, pinged the relevant IRC
channel and have generally tried to let people know about this. The
actual macros are in the pagure repo but there's still more work to be
done. https://pagure.io/python-macros
- J<
--
devel mailing list
devel@lists.fedorapr
> "MB" == Mike Bonnet writes:
MB> That sounds like a good plan. Is this work being tracked anywhere?
As you might expect, in an FPC ticket:
https://fedorahosted.org/fpc/ticket/567
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/de
Luckily I saw this. The best way to make sure the packaging committee
sees this kind of thing is to open a ticket at
https://fedorahosted.org/fpc/
However, I don't believe your assertion to be true. python*-devel is
the package with the dependency on the RPM macros; if you depend only on
python
> "AT" == Antonio Trande writes:
AT> Probably i taken too much seriously this "type of joke", so much
AT> that this issue does not deserve any answer.
Well, if the license text says "you must buy me a beer of you see me" or
whatever then that would render the software non-free regardless. I
> "AT" == Alexander Todorov writes:
AT> offending packages. You can find links to the script and execution
AT> log here:
AT> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
BTW to see if any packages you own are on the list, you can do:
wget
https://raw.githubuse
> "AW" == Adam Williamson writes:
AW> I think the fact that we can't even have a discussion of this where
AW> we both understand what the current rules actually *are* clearly
AW> indicates they have a clarity problem =)
You may recall my earlier message in this thread where I indicated that
> "AM" == Adam Miller writes:
AM> I also like the proposal for the bundled() macro definition
AM> for tracking purposes.
Just a note that it isn't a proposal; that is the current requirement
for anything which bundles things.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https:
> "AW" == Adam Williamson writes:
AW> That just says 'multiple, separate upstream projects' (nothing about
AW> being 'compiled in'), and implies that absolutely any such case can
AW> only be included with an explicit 'Bundling Exception'.
OK, so "compiled in" isn't really the right term if y
> "MM" == Matthew Miller writes:
MM> I think it's because overriding a different group seems hostile,
MM> even if it isn't meant that way. And FESCo doesn't want to feel like
MM> they're second-guessing other groups all the time.
Well, FPC even has a "bounce to FESCo clause" in the rules we
> "SS" == Simo Sorce writes:
SS> I have the impression (which may be totally wrong) that you are
SS> taking the binary approach here: either we care maximally or we do
SS> not care at all.
I sure hope that's not the tack I'm taking.
SS> It seem to me Stephen is making a proposal to tweak ju
> "MM" == Matthew Miller writes:
MM> That said, I do recognize that "provides high-quality packages" has
MM> also always been an underlying Fedora value even if unstated. But, I
MM> think that _that_ value should be in support of the Big Four, and in
MM> support of our mission in general, not
> "SG" == Stephen Gallagher writes:
SG> Right now, we have a policy that essentially forbids source code
SG> from being bundled into a package.
Technically we only care if that bundled code is actually compiled in.
SG> In technical terms, this means essentially that the packaging
SG> polici
> "H" == Haïkel writes:
H> Using Bugzilla rather than FAS is not a bad idea, as some people
H> abuse their sponsor status by blindly adding people into the packager
H> group without any supervision. Using FAS as the information source
H> would just hide this hideous behaviour.
I don't know
> "VS" == Ville Skyttä writes:
VS> I have a bug report about the macros. Where should I file it, FPC
VS> ticket or Bugzilla against the python* packages that ship the
VS> affected macro files?
Oops, I didn't see your mailing list post until well after I saw the
ticket.
Unfortunately this ki
Here are the recent changes to the packaging guidelines.
-
The big change is that the Python guidelines have been extensively
reorganized and partially rewritten, and new macros are available which
simplify packaging by removing some of the boilerplate which was
previously required.
The main
Here are the recent changes to the packaging guidelines. Note that
there is also a set of Python guideline changes pending which I will
send in a separate announcement.
-
Guidelines for making use of weak dependencies (Recommends:, Suggests:,
etc.) have been added.
*https://fedoraproject.
> "RSB" == Ryan S Brown writes:
RSB> I disagree; for server & cloud deployments it doesn't make sense to
RSB> duplicate a DNS server on *every* host, and if you care about
RSB> DNSSEC you likely already run a trusted resolver.
I disagree generally in the case of server deployments.
Having a
Here are the recent changes to the packaging guidelines:
The policy for systemd presets has been modified to merge the
individual treatments of service, socket and timer units into one
policy. The policy page was also moved into the packaging guidelines
proper.
* https://fedoraproject.org/wiki/Pa
> "AT" == Antonio Trande writes:
AT> Is it a problem if i downgrade the current release of SeqAn on pkgdb
AT> until the new 2.0.0 is fully ready ?
I'm not sure what pkgdb has to do with that; it doesn't track versions.
Basically, if you didn't have a successful non-scratch koji build (and
i
Here are the recent changes to the packaging guidelines:
The guidelines for packaging static libraries were amended to indicate
that the -static package should require the -devel package:
*
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries_2
*
https://fedoraproject
> "KM" == Kelly Miller writes:
KM> I just tried to mount my home folders using NFS as I usually do, but
KM> no matter what I get the error mount.nfs: requested NFS version or
KM> transport protocol is not supported. Did something change in the
KM> Alpha of Fedora 22 to suddenly break NFS mou
> "EM" == Elder Marco writes:
EM> So, upstream recommends to deal with "plowshare" core only, which it
EM> is quite stable. And I agree.
Well, look at how clamav does it. The package provides a snapshot of
the virus data so that we can ship _something_. This will be updated
when freshclam
> "MC" == Matěj Cepl writes:
MC> Cutting up texlive monster piece by piece seems like rather lousy
MC> idea to me.
I honestly don't see why. Surely fixing some of it is better than
fixing none of it. And fixing some of it shows us how to fix the rest
of it.
- J<
--
devel mailing list
de
> "MJ" == Marcin Juszkiewicz writes:
MJ> When I was Debian/Ubuntu developer it was easy. Pbuilder had hooks
MJ> and one of them in my setup was "once built, install all resulting
MJ> packages".
MJ> This way as a developer I could check are results usable. Not found
MJ> something like that in
> "MC" == Matěj Cepl writes:
MC> Now, the question is how to build just one subpackage (or any
MC> required other subpackages) from the monstrosity which the current
MC> texlive? Anybody any suggestions?
Just package it separately. They should all have proper upstream
tarballs, and there's
I'm orphaning the zoneminder package on all branches. Feel free to pick
it up if you wish to maintain it.
Zoneminder is a security camera monitoring system. Back in the dark
days of history I ended up becoming the de-facto maintainer when the
original maintainer went away, though he still owned
Following is the list of topics that may be discussed in the FPC meeting
Thursday at 2015-04-02 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2015-03-12 09:00 Thu US/Pacific PDT
2015-03-12 12:00 Thu US/Eastern EDT
2015-03-1
> "ML" == Mark Lamourine writes:
ML> "build at runtime"?
Generate the tarball or whatever image you need at runtime. When it's
needed. Not as part of the package build, because I can't see a way
that such a thing would be permitted under current Fedora policies. You
have runtime dependenc
> "ML" == Mark Lamourine writes:
ML> Is there a recommended way to retrieve, extract and track the files
ML> so that they can be compiled into the gzipped tarball which can then
ML> be included in a package?
I cannot think of anything in existing Fedora policy which would permit
that.
You c
> "LM" == Lokesh Mandvekar writes:
LM> There seem to be a few issues with it currently though, the major
LM> one being using a non-distro-provided systemd (systemd v215):
Just a note that in my opinion there is essentially no chance that the
packaging committee would approve a bundling excep
> "GH" == Gerd Hoffmann writes:
GH> Makes sense to me, not only for texlive, stuff like perl pkgs from
GH> cpan have pretty standard way to be built too.
It's not just how the packages are built. There are also bundling and
license issues which require manual inspection. The only reason fo
> "MM" == Matthew Miller writes:
MM> Basically, this is an end-run around the requirement of doing
MM> individual package reviews for a zillion completely separate
MM> packages, right?
That was my opinion, but you could argue the same for Perl, I suppose.
We're essentially packaging a comple
> "KL" == Kalev Lember writes:
KL> What do you mean with "were required to" ?
There were many discussions during and after the big texlive license
audit as to how to properly package the software. I can no longer
remember exact dates because it's been a while; maybe someone else has a
bette
> "KL" == Kalev Lember writes:
KL> If texlive packaging is causing issues with update pushes, could
KL> maybe ask the texlive maintainers to rework the packaging?
The texlive packaging is basically the way they were required to do it
way back when. It used to be just a big ol' "texlive" pac
> "KF" == Kevin Fenzi writes:
KF> Right, as I noted at the end of that other long mail, there's
KF> discussion about a 'urgent updates' repo for security updates.
Why not, when going to mash, mash only updates marked a security and get
those out immediately, then mash everyhing else. Is the
Here are the recent changes to the packaging guidelines:
The documentation section of the guidelines has been updated to include
a prohibition on using both %doc and direct installation of files into
%_pkgdocdir.
* https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation
*
https://fedo
> "KF" == Kevin Fenzi writes:
KF> I know in the past the FPC has talked about relaxing the bundling
KF> guidelines, perhaps we could get some of them to weigh in here?
Yeah, we had a big discussion about that a while back, where we sort of
agreed on a basic change of philosophy regarding som
A few more changes this week:
The Byte compilation section of the Python packaging guidelines was
rewritten to include information about packaging the pycache directories
generated by newer Python versions.
https://fedoraproject.org/wiki/Packaging:Python#Byte_compiling
https://fedorahosted.org
> "RS" == Richard Shaw writes:
RS> Is this retroactive on all supported versions of Fedora?
Packaging guideline changes are pretty much never retroactive; we don't
really have an enforcement body.
RS> 20+?
Well, <20 isn't exactly important.
RS> What about EPEL 5, 6, 7?
Pretty sure 7 is O
%license must be used in place of %doc to designate any file containing
the license information for a package. See
https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation and
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines
Guidelines for DevAssistant packages (DAP) were
> "PT" == Pete Travis writes:
PT> Maybe some list or other communication channel that's more clearly
PT> for packaging issues - I'm told devel@ can be intimidating - would
PT> help, but I'm not really suggesting anything specific.
Just to be sure, you do know about packag...@lists.fedoraproj
> "DM" == Dominik 'Rathann' Mierzejewski writes:
DM> I meant each new release of freefem++. The build process tries to
DM> download sources for many external libraries and patches some of
DM> them, so you have to work around it.
Hmm. I looked at the patches and they don't look _too_ bad. I
> "DM" == Dominik 'Rathann' Mierzejewski writes:
DM> Dear Fedora Community, I'm orphaning the freefem++ package[1] since
DM> I don't have access to anyone that uses it and despite having an
DM> active upstream, it's a pain to get it to build with each new
DM> release.
Crap, I have people her
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2013-07-25 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net. Note that there was no meeting last week, and that
time constraints will probably prevent us from getting through the
entire volume of new business t
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2013-07-18 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2013-07-18 09:00 Thu US/Pacific PDT
2013-07-18 12:00 Thu US/Eastern EDT
2013-07-18 16:
> "MT" == Miloslav Trmač writes:
MT> For example, right now the easiest way to become a Fedora packager
MT> is still to learn RPM packaging (only) and add a new package (which
MT> will, by now, fairly often be something obscure with a few hundred
MT> of users),
That is actually quite untrue
> "MS" == Miroslav Suchý writes:
MS> 1) What about those old merge requests?
Don't know; didn't do merge requests. You or anyone else is of course
welcome to look at the list; there's a whole report for them.
MS> 2) Why is not on that list some packages which are still waiting for
MS> revi
I spent a bit of time recently trying to clean up the oldest package
review tickets, making sure links are accessible and the submitted
packages actually build. At this point I think all of the tickets in
http://fedoraproject.org/PackageReviewStatus/NEW.html older than May
2012 should actually be
> "NM" == Nicolas Mailhot writes:
NM> I don't think selinux will block web server accesses to
NM> /usr/share/fonts/something, since we deploy webapps in
NM> /usr/share/something_else, which is pretty much the same namespace.
Well, there are a whole lot of specific fcontext entries for conten
> "NM" == Nicolas Mailhot writes:
NM> I'm not convinced at all this needs changing, since mod_alias
NM> permits mapping of system paths anywhere you want in your URL space.
But selinux probably doesn't, so the issue is slightly more complicated.
- J<
--
devel mailing list
devel@lists.fedo
> "RC" == Remi Collet writes:
RC> Have you notice than all this bugs depend on #871373 which provides
RC> some useful information ?
The useful information was not in the ticket. Which means it wasn't in
the email. Which means I had to get over to a web browser, wait for
bugzilla to load, a
It would have been super nice to actually include a link in all of those
bugs, or some reference. I mean, they must have been filed by program,
so it's not as if you would have had to do a bunch of extra typing.
We really need a "mass bug filing howto" or something. Preferably
starting with "Don
> "LZ" == Lukas Zapletal writes:
LZ> Hello, I have noticed that latest "tig" update in Fedora 17 changed
LZ> it's behavior.
tig has not ever been updated in F17; it still has the same 0.18-2
release that was there when F17 was spun.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
> "RL" == Robin Lee writes:
RL> Hi, all I want to follow the route [1] to bring up a new
RL> packager.
Then why not follow the procedure you referenced? It tells you what to
do, which involves opening a ticket in the appropriate trac instance.
- J<
--
devel mailing list
devel@lists.fedor
> "MC" == Michael Cronenworth writes:
MC> The guidelines now force any package that has Emacs add-ons to
MC> install them in the main package and Requires:
MC> emacs-filesystem. Emacs is not installed by default and I do not use
MC> Emacs, nor will I ever.
emacs-filesystem consists of three
> "JF" == John Florian writes:
JF> Now, if the mouse pointer could also reverse upon detecting the
JF> apparent handedness of the user, well that would be one of the
JF> coolest UI tricks ever.
I certainly hope not; I'm left handed and would never dream of switching
the mouse around, given
> "GH" == Garrett Holmstrom writes:
GH> I am pleased that I got a bug report and not an involuntary patch,
GH> as it gives me a chance to take care of special cases and schedule
GH> things appropriately.
I would much have preferred to receive an announcement about what should
be done, some d
> "Ri" == Rave it writes:
Ri> For your information. I stoped working for the Mate-Desktop project
Ri> for f18 because for me it is imposssible to to work together with
Ri> Dan Mashal. One of the reason for my decision is this last talk with
Ri> Dan Mashal today.
I've watched a bunch of this
> "JB" == Josh Boyer writes:
JB> Right. There's a bug open for it somewhere.
https://bugzilla.redhat.com/show_bug.cgi?id=826707
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> "RWMJ" == Richard W M Jones writes:
RWMJ> I just received about a dozen bugs like this:
Yep, someone has taken it upon themselves to mass-file a bunch of
unnecessary tickets.
When FPC makes guidelines changes, they aren't generally accompanied by
some mandate that existing packages be cha
> "RC" == Ralf Corsepius writes:
RC> Hi, f18 seems to be missing in bodhi.
RC> I.e., ATM, it seems impossible to push packages to f18.
Until today, f18 is like rawhide; you build and it goes in at the next
compose.
After the switch is made, f18 acts like f17. That should happen today;
I do
> "MC" == Matěj Cepl writes:
MC> (sorry, once more, this time to the correct address)
And now a public reply
MC> I thought that the rule is that Fedora packages shouldn't contain
MC> just a pure content.
That is incorrect, pretty obviously if you think about it. I mean, how
is man-pag
> "MC" == Matej Cepl writes:
MC> Isn't it breaking
MC> https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
MC> ?
Maybe you should tell us why you believe it is. I don't see how it
violates any of the rules for content.
- J<
--
devel mailing list
devel@lists.fedoraproject.
> "PU" == Patrick Uiterwijk writes:
PU> Hello, Would it be a possibility for me to pick up one of the
PU> orphaned packages, without being sponsored into the packager group
PU> yet?
The answer is of course no, but he's now been sponsored and is free to
take ownership of some of those package
> "DC" == Dan Callaghan writes:
DC> I will take all three (they look straightforward :-) in exchange for
DC> saslwrapper:
Since you appear to be familiar with sugar, is there any possibility
that you (or anyone else who is familiar with sugar stuff) could cast a
glance at https://bugzilla.re
> "IRP" == Itamar Reis Peixoto writes:
IRP> Summary of changes: 73f7b54... Migrate to systemd. (*)
I'm sure you already know this, but just in case, please note that
migrating to systemd within a release is forbidden. You really
shouldn't even be committing any kind of systemd migration to
> "TL" == Tom Lane writes:
TL> Did that packaging guideline get reverted already?
No, it didn't, but of course you know the packaging committee cannot
prevent an upstream from implementing whatever functionality they like.
We can of course revisit the prohibition if someone cares to file a
t
A while back, FESCo approved and I implemented some changes to the
process of becoming a sponsor in the packager group, and I wanted to
make sure that everyone is aware since the path to becoming a sponsor is
shorter and simpler than ever before.
The most important change is that sponsor status no
> "MR" == Matthias Runge writes:
MR> exactly, I fully agree. I think, we should lower the barrier to
MR> become a sponsor, maybe dropping the necessity to become a proven
MR> packager first.
I can't quite tell; are you aware that this is the core point of the
proposal I've put forward at the
> "MS" == Michael Schwendt writes:
MS> Are we talking past eachother? :-/
I don't believe so, no. I do believe that you are reading something
into my proposal that simply is not there, however.
MS> What if sponsors _try_ but for some time haven't found anyone who
MS> shows enough interest
> "MS" == Michael Schwendt writes:
MS> There are a few unfortunate sections in the first paragraph already:
Except that they're all true.
>> users have to go through an almost endless set of steps (which also
>> needs revision, but that's another topic)
MS> Compared with a few years ago the
> "KD" == Ken Dreyer writes:
KD> Looks good to me. I was unaware that sponsors are (currently) also
KD> provenpackagers. I've considered the idea of becoming a sponsor
KD> myself, but when I read the archived tickets where other people
KD> smarter than me have been denied, the barrier to entr
For a while now I have been working on a proposal for some changes to
both the way we elevate packagers to sponsors and what (to a small
extent) sponsors actually do. Please note that this is not a proposal
for any changes to how people are made members of the packager group in
the first place and
> "IM" == Ian Malone writes:
IM> So, what's the next step? If necessary I can volunteer to maintain
IM> it myself (and would have to volunteer as a maintainer), but would
IM> be more than happy for someone else to take it.
Well, assuming that nobody else takes it, and also assuming that you'
> "JO" == Joe Orton writes:
JO> Yup - the default config in the f18 httpd does load
JO> mod_access_compat, and I don't see a problem with shipping like
JO> that.
This is good news, because even if we convert the httpd.conf.d files in
all of the packages, they're all marked %config(noreplace)
> "SS" == Simo Sorce writes:
SS> I guess it is time to change habits, what's the point of a separate
SS> /usr these days ?
I also always configured a separate /usr until I decided to obey
systemd's complaints about it being broken (though of course I never had
any issue at all with it). For
> "PP" == Petr Pisar writes:
PP> zoneminder
Went ahead and rebuilt it now as I intend to be working on it tomorrow.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> "dp" == darrell pfeifer writes:
dp> As far as I've seen on the list, the /usr move stuff was supposed to
dp> be confined by tagging to f17-usermove so it wouldn't affect rawhide
dp> until the big switch was pulled.
Well, yes, but the big switch has actually been pulled.
- J<
--
devel ma
> "MC" == Mike Chambers writes:
MC> Did my eyes deceive me, or do the packages now get separated and put
MC> in their respected dir of their first letter, and not located in one
MC> dir now?
Yes.
MC> Did the tree change or is this an error?
The tree changed.
- J<
--
devel mailing list
d
> "RR" == Roman Rakus writes:
RR> How are fedora with grub2 users supposed to set up crashkernel
RR> kernel argument? Or even any argument?
One possibility is /etc/default/grub. This contains
GRUB_CMDLINE_LINUX. After changing that, grub2-mkconfig -o
/boot/grub2/grub.cfg.
You can also edi
> "RS" == Richard Shaw writes:
RS> Yes. If the informal review is for an existing packager then,
RS> there's no guarantee that a sponsor will even see that informal
RS> review because there's no requirement for a sponsor to approve the
RS> review request in that scenario.
You must have misun
> "RS" == Richard Shaw writes:
RS> How does someone who needs to be sponsored make sure that their
RS> informal reviews get noticed? Not everyone will 'toot their own
RS> horn' so to speak. That doesn't mean they are not a good prospect as
RS> a packager.
Well, the documentation says to incl
> "RS" == Richard Shaw writes:
RS> Perhaps this has been discussed before I'm
RS> not aware of it but do we really need to hold up a package because
RS> the submitter needs a sponsor?
Yes, definitely.
RS> Does this make sense?
Yes, it makes a lot of sense. We need to set some minimal limi
> "TH" == Tom Hughes writes:
TH> As somebody who is in exactly that situation all I can say is that
TH> if doing informal reviews is an essential prerequisite to getting
TH> sponsored then the wiki could be a lot clearer. Currently it reads
TH> more like it's just one thing that may help.
It
> "VO" == Vít Ondruch writes:
VO> It would be reasonable, on the beginning of each development cycle,
VO> to publish a list of packages which were not touched by it
VO> maintainer in previous release.
I certainly hope you realize that there are very many packages in the
distribution that sim
> "JBG" == Jóhann B Guðmundsson writes:
JBG> How does FPC handle packagers that violate the packaging
JBG> guidelines?
FPC is not tasked with enforcing the packaging guidelines.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> "JK" == Jesse Keating writes:
JK> I don't believe you can delete a branch remotely, I think releng has
JK> to do it on the server. Yes, you could still ask releng to delete a
JK> branch, then you could re-create it with the same name and have the
JK> same net effect, however we don't let d
> "RS" == Richard Shaw writes:
RS> After some initial interest there doesn't appear to be any activity
RS> unless I'm missing something.
Never could gather enough interest for anyone to actually do anything.
Basically I stopped after I called for a couple of folks to help me with
some things
> "SB" == Sergio Belkin writes:
SB> I'd want to notify that rmplint warns about "BSD with
SB> attribution",
Please file a bug against rpmlint.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> "NP" == Nils Philippsen writes:
NP> Legal question: is it better to put this in its own subpackage to be
NP> able to specify this individual license, or would GIMP better have
NP> "GPLv3+ and LGPLv3+ and (GPLv2 or GPLv3)" as its license?
This is covered by
http://fedoraproject.org/wiki/Pac
> "IA" == Iain Arnell writes:
IA> The only documentation I'm aware of is the same draft you're working
IA> on.
Ah, OK. For some reason I interpreted what I read to say that the Perl
filtering macros had been rewritten to make use of the new filtering
system. I'm still hoping that's possibl
> "NO" == Nathan Owe writes:
NO> Yep old code does tend to work, but also this also means that
NO> security or runtime bugs that are around won't be fixed either,
NO> atleast upstream.
Right, which is why I wrote that you should ask the submitter if they
are willing to take on the full maint
> "NO" == Nathan Owe writes:
NO> Should I let the submitter know that it is this old or should it be
NO> closed or the age of the upstream source ignored, in which I am
NO> guessing the later is not the case.
Well, I could certainly ask the submitter if they're aware that the code
they're pa
> "IA" == Iain Arnell writes:
IA> The perl_default_filter macro changed with perl 5.14. We're now
IA> using rpm's native __requires_exclude macro (and friends) instead of
IA> the slightly hacky filter_setup stuff.
Really? Is there documentation for how this is supposed to work now?
There's
> "HdG" == Hans de Goede writes:
HdG> Hi,HHdG> Tomas has chosen to fix this problem by simply disabling the
HdG> openssl compat part of gnutls (which as the above bug shows is
HdG> broken by design) given that only 3 apps use this, this seems like
HdG> a sane choice to me.
Except, of course,
> "SO" == Stanislav Ochotnicky writes:
SO> I believe you forgot to set whenisgood to use timezones :-)
My understanding is that you have to log in in order to set your
timezone, or that choosing a timezone was something the responder had to
do. When I created the form, "Use timezones" was c
So, that was pretty good response; only one reply here, but several
names were added to the wiki page. There seem to be enough people
interested to begin moving forward.
I can't think of a better place for discussion than this list, so I'll
just go ahead:
Could someone volunteer to co-chair this
For a while now I've wanted to get some sort of package review SIG
going. The package review process hasn't really evolved much since it
was instituted way back when, and now it (and the portion of the
sponsorship process it overlaps) has become a major bottleneck in one of
the main ways of gettin
401 - 500 of 562 matches
Mail list logo
