> "JS" == Jochen Schmitt writes:
JS> I'm only a ordinary provenpackager without any additional access to
JS> the kernel package.
Provenpackagers have write access to the kernel package. What exactly
do you think has gone wrong here?
- J<
--
devel mailing list
devel@lists.fedoraproject.or
Some Red Hat employees are opening new merge review tickets for packages
which were in extras long before the big core-extras merge. It looks
like all of these packages are so old that the reviews predate the use
of Red Hat's bugzilla for the purpose, and so those reviews were either
done on the o
> "BN" == Bill Nottingham writes:
BN> There is a new internal process that encourages that packages have
BN> existing Fedora reviews.
Please define "internal". If this is some Red Hat internal thing, don't
you think the community who is being asked to do this work should at
least be informe
> "MS" == Michael Schwendt writes:
MS> More than a dozen Red Hat people with "commit" access, but access
MS> was "denied" to one other Red Hat employee. Why?
You'll find that for some odd reason xiphmont has commit set to "Denied"
on several packages. I've never understood why it ended up t
> "RWMJ" == Richard W M Jones writes:
RWMJ> Is there any essential difference between 'fedpkg push' and plain
RWMJ> 'git push'?
def push(self):
"""Push changes to the main repository"""
cmd = ['git', 'push']
_run_command(cmd)
return
So looks like no.
-
> "JP" == John Poelstra writes:
JP> Also *PLEASE* make sure any scripts or other external applications
JP> that rely on bugzilla.redhat.com are tested against our test server
JP> before the upgrade if you have not done so already (see original
JP> email below).
Unfortunately the test instanc
> "BN" == Bill Nottingham writes:
BN> I can't help but note that the slips have become more frequent as we
BN> started to actually *have* release criteria to test against. We
BN> didn't slip nearly as much when we weren't testing it.
To me this implies that we should begin testing earlier (o
> "MM" == Mike McGrath writes:
MM> Possibly also stop changing earlier?
Not necessarily. We should certainly try to get the earth shattering
changes done as early as possible (i.e. soon after branch) but I
recognize that there isn't sufficient developer time available to both
stabilize one
> "JN" == Joe Nall writes:
JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
>> More to the point, I can easily see the setuid bit easily on a
>> binary.
>> How do I tell if these strange/hidden "capabilities" are
>> present on a binary? 'ls' doesn't mention anything.
JN> getcap
Yeah, it looks like the capabilities thing has broken my buildsystem:
Error unpacking rpm package iputils-20101006-2.fc15.x86_64
error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file
failed - Operation not supported
Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x
> "SO" == Stanislav Ochotnicky writes:
SO> Java SIG has prepared changes in current Java packaging
SO> guidelines. We would welcome wider discussion/comments at this
SO> point. From our point of view guidelines seem ready for approval by
SO> FPC.
Could we get a diff of these guidelines again
> "SO" == Stanislav Ochotnicky writes:
SO> Java SIG has prepared changes in current Java packaging
SO> guidelines.
It's terribly rude to crosspost to a list which simply rejects messages
from non-subscribers.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedorapro
> "SO" == Stanislav Ochotnicky writes:
SO> Recently? I haven't heard of Java-specific guideline changes for
SO> past few months. Care to enlighten me?
https://fedorahosted.org/fpc/ticket/13
http://lists.fedoraproject.org/pipermail/devel-announce/2010-October/000699.html
- J<
--
devel ma
> "RC" == Ralf Corsepius writes:
RC> In other words, as far as I am concerned, abrt has reduced
RC> efficiency of bug-hunting by flooding maintainers with low quality,
RC> often unusable reports and risen the communication churn related to
RC> BZs.
It's been discussed many times and I still
> "TK" == Toshio Kuratomi writes:
TK> They are now optional but there's no need to force people to be rid
TK> of them. In particular, some people like to build a package for both
TK> Fedora and EPEL-5. In this case, a lot of the things that are
TK> optional in Fedora have to remain for the E
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
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
> "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
> "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,
> "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
> "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
> "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
> "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
> "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
> "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
> "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
> "TL" == Tom Lane writes:
TL> Do we need to wait around for somebody to fix these stragglers, or
TL> can we go ahead and release dist-f15-mysql into the general
TL> f15-testing pool?
Please do not wait on zoneminder. It was broken before this due to an
unrelated issue which should be fixed
> "ES" == Emmanuel Seyman writes:
ES> It's a mistake. I wanted to upload the source tarball and picked the
ES> wrong file. Is there anything for me to undo?
It is pretty much permanently in the git repository, and anyone who
does a non-shallow clone of the package will have to download that
Erm, I guess I misread. I thought the file had been checked into git,
rather than uploaded to the lookaside. Checking big binaries into git
is a problem, uploading them to the lookaside isn't.
I can remove it from the lookaside if that's really necessary, but
there's really not much reason since
> "GH" == Garrett Holmstrom writes:
GH> How is this any different, given that process-git-requests creates a
GH> rawhide branch without regard to whether one asks for it or not?
I'm catching up with mail after the weekend and noticed this unusually
pointed bit of misinformation which bears c
> "NU" == Nikolay Ulyanitsky writes:
NU> Some maintainers use them, some do not.
I guess people who really like extra typing, wrist pain or spec files
which are difficult to read would use them.
NU> What is recommended way?
It's up to you, but something like "%{__cp}" is absolutely pointle
> "OP" == Orion Poplawski writes:
OP> The install spends a long time displaying "Checking dependencies in
OP> packages selected for installation" with no movement of the progress
OP> bar.
My kickstart installs used to sit showing that for ages; I ended up
using pungi -G to gather an install
> "BW" == Bruno Wolff writes:
BW> Please update us on when he is ready for bug reports for that
BW> version. Several 3d games don't work.
I don't think anything's actually expected to work at this point.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.
> "JL" == James Laska writes:
JL> Greetings folks, Is anyone interested in sponsoring a new package
JL> used in several upcoming AutoQA test cases?
We don't sponsor packages, we sponsor packagers. Has the packager in
question done any other review work? Submitted other packages for
inspec
> "AW" == Adam Williamson writes:
AW> I think it was just a thinko for 'review'.
In which case, why would a sponsor be required at all? James is in the
packager group, so he could just do the review. According to the ticket
in question, a sponsor for the packager is required (FE-NEEDSPONSO
> "JL" == James Laska writes:
JL> I take it from your response that you're not interested in reviewing
JL> and sponsoring this package review request?
Again, we don't sponsor packages or package review requests. We sponsor
packagers. Packagers need to demonstrate various things before some
> "TK" == Toshio Kuratomi writes:
TK> Querying bugzilla is a comparatively expensive process so it's
TK> probably something we need to do by syncing the count of bugs into
TK> the db via a cron job. Any takers?
I could probably whip something up.
- J<
--
devel mailing list
devel@lists.fe
> "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
> "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
> "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
> "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
> "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
> "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> 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
> "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
> "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
> "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
> "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
> "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
> "RK" == Rudolf Kastl writes:
RK> Hello, I wanted to point out that about a month and a half ago intel
RK> released a new driver version 2.13.0. Could we please have an update
RK> in rawhide?
Currently rawhide seems to be at 2.13.901, a development version past
the one you are requesting.
> "RK" == Rudolf Kastl writes:
RK> http://koji.fedoraproject.org/koji/packageinfo?packageID=7794
RK> guess you pulled that somewhere else.
fedpkg co xorg-x11-drv-intel; less xorg-x11-drv-intel/*spec
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/m
A few folks have sufficient access to log into the builders and strace
things if necessary. You're welcome to ping me on IRC.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> "IG" == Ilyes Gouta writes:
IG> Can we have this patch back ported into the current kernel for
IG> Fedora 14 and possibly posted as an update? :)
IG> Would be wonderful!
Would be more wonderful to wait until the upstream development has
actually finished before cramming it into our package
> "RWMJ" == Richard W M Jones writes:
RWMJ> I will take ocaml* and unison*.
I have orphaned them; feel free to take ownership.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> "MF" == Mike Fedyk writes:
MF> Hopefully some better spam filtering can be implemented so that
MF> fedora's mail servers don't end up in spam block lists anymore.
Spam filtering will never prevent every spam from getting through. The
host forwards lots of mail; people are going to falsely
> "PP" == Petr Pisar writes:
PP> I can take: pl, yap.
They should be orphaned in pkgdb; you'll need to log in and take
ownership.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> "VS" == Ville Skyttä writes:
VS> It seems that the %jpackage_script tip/guideline did not make it
VS> into this revision, was there a reason for that or did it just fall
VS> through the cracks?
That was not part of the draft which we considered. Currently there are
no Java-related drafts
> "SD" == Steve Dickson writes:
SD> So what/where are the steps I need to take to retire nfs-utils-lib
SD> and create a new libnfsidmap package...
http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
And I think you're probably pretty familiar with the process of
submitting
> "AH" == Adam Hough writes:
AH> Someone with that right permissions need to change who maintains the
AH> openjpeg package in Fedora.
It has two comaintainers, so I don't really see what the issue is.
I went ahead and gave those comaintainers approveacls permission on the
Fedora branches so
> "MP" == Michał Piotrowski writes:
MP> How can I get information about all packages that provides init
MP> scripts?
repoquery --whatprovides '/etc/init.d/*'
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> "PM" == Panu Matilainen writes:
PM> In particular, I'm interested in feedback on the new, pluggable and
PM> enhanced dependency extration system. Documentation is scarce at the
PM> moment but some background and examples can be found here:
PM> http://laiskiainen.org/blog/?p=35
Unfortunatel
> "MC" == Milan Crha writes:
MC> Could you give me a link to the proper PackageDB
MC> page, please?
Personally I just go to http://bugz.fedoraproject.org/packagname and
click the "Package Info" link.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/
> "MC" == Milan Crha writes:
MC> I see [1] the libical is not orphaned yet, neither in devel, nor in
MC> F14, as I "only" can add myself to the package, but not take
MC> ownership as with other orphaned packages.
Well, currently it has a maintainer (and a comaintainer for the Fedora
branches
> "MP" == Michał Piotrowski writes:
MP> Dear FPC people, could you provide this list in the near future?
We haven't even met since it was decided that we were to do this. I
imagine it would take a couple of meetings to bang out a list.
- J<
--
devel mailing list
devel@lists.fedoraproject
> "PR" == Peter Robinson writes:
PR> My understanding was that if it was blocked it had to go through
PR> review again.
Depends on how long:
http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers
"
Re-review required for older packages
If a package was last updated more
> "GD" == Gilboa Davara writes:
GD> Hello all, While the click-frenzy required to take ownership over
GD> spring and its sub packages I mistakably retired spring-maps-default
GD> / devel and spring-install / devel. I tried to unretire them both,
GD> but failed.
You've found one of the worst
OK, I found spring-installer and unretired it as well. You should log
into pkgdb and claim both packages as they're currently orphaned.
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> "JS" == Jochen Schmitt writes:
JS> because I have read, that new contributors should not applies
JS> membership on the packagers group and the sponsor should invites
JS> them to this group,
Well, nobody can apply to the packager group; it is invite-only. There
may be a few people in the s
Well, you missed yesterday morning's run and I skipped over that package
in this morning's run because the ticket isn't assigned to anyone. I
intend to go back over the tickets I skipped, figure out what's gone
wrong with them and add comments but I have not yet found the time to do
that today.
A
> "JC" == Jon Ciesla writes:
JC> I can't recall at the moment where this stems from, but the
JC> rationale, as I recall, was that we can never be sure if the
JC> database is available at RPM install/upgrade time.
It's pretty simple. Creating databases isn't generally something that
an rpm c
> "MC" == Matthias Clasen writes:
MC> * gtk-update-icon-cache-3.0 and gtk-builder-convert-3.0 have been
MC> dropped (since they were identical to their un-suffixed cousins in
MC> the gtk2 package). If you are using gtk-update-icon-cache in %post
MC> of a gtk3-using package, you should add Req
> "ss" == susmit shannigrahi writes:
ss> Not sure where it should go inside packaging guidelines. Can anyone
ss> else please do that?
Packaging guidelines are modified by the packaging committee and are not
generally editable. You are welcome to submit a draft for
consideration; just create
> "NM" == Nathaniel McCallum writes:
NM> https://bugzilla.redhat.com/show_bug.cgi?id=625187 This bug
NM> basically makes Fedora completely unusable in rawhide for NVA{3,5,8}
NM> users.
Isn't that just https://bugs.freedesktop.org/show_bug.cgi?id=26980 ?
If so, the hardware is basically unsu
> "AW" == Adam Williamson writes:
AW> that's not the problem. rpmlint just thinks you usually shouldn't do
AW> anything with the build root in certain sections of spec files and
AW> so complains if it sees usage of any buildroot definition
AW> ($RPM_BUILD_ROOT or %buildroot) in those sections
> "RWMJ" == Richard W M Jones writes:
RWMJ> I thought that was all I had to do, but apparently there's
RWMJ> something else needed to drop it entirely.
Did you delete all of the files and add a dead.package file?
http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
- J<
--
> "pm" == philippe makowski writes:
pm> You mean that the initscript provided by upstream should be changed
pm> ?
Yes.
pm> chkconfig: 345 80 20
pm> chkconfig: - 80 20
- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
>New package: ghc-process-leksah-1.0.1.4-2.fc15
> Haskell process-leksah library
Is it not possible to try a little harder to write a useful package
summary? Or for the package reviewer to take just a quick look and
notice that a summary such as that is pretty much completely useless?
> "GvE" == Gerd v Egidy writes:
GvE> What is the best way to handle this? Can I keep one spec for both
GvE> and use conditionals to always build the right way?
You can. Do keep in mind, however, that the amount of conditional
garbage you have to pile into the spec file can get to be a bit m
> "MC" == Michael Cronenworth writes:
MC> I don't know why, but it wouldn't be a bad thing to have it in the
MC> repository like a normal package, IMO.
Not that this will really explain anything, but:
https://bugzilla.redhat.com/show_bug.cgi?id=563176
- J<
--
devel mailing list
devel@lis
> "TM" == Till Maas writes:
TM> Is there any reason to only package the two tools I need and add
TM> others whenever someone requests it? Would someone disapprove this
TM> in a package review?
I don't see what would require you to package every piece of
functionality included in a upstream t
> "SB" == Sergio Belkin writes:
SB> I've made yesterday a Package SCM admin request and I haven't
SB> received a notification yet.
Well, you made your request just after I had processed the queue
yesterday and chose to complain before I had processed the queue this
morning.
SB> I'm not in a
> "PL" == Peter Lemenkov writes:
PL> Sometimes *-javadoc sub-packages explicitly requires main
PL> package, and sometimes - not. I'm not a java-expert, so I don't know
PL> which is correct.
Java guidelines have come up recently on the packaging list.
The templates in the Java packaging guid
> "AH" == Alex Hudson writes:
AH> So Red Hat's lawyers know that Red Hat are distributing something
AH> which they have no license for, so either they haven't passed that
AH> message on or Red Hat have decided they don't care?*
http://en.wikipedia.org/wiki/False_dilemma
- J<
--
devel mail
> "BI" == Bernie Innocenti writes:
BI> A Debian user told me that Debian carries a glibc patch to make
BI> processes notice resolv.conf updates and reload it. Is there any
BI> chance we could apply the same patch in Fedora too? I don't know all
BI> the details, but I guess there might be a g
> "TK" == Toshio Kuratomi writes:
TK> * What replaces chkconfig
TK> * What replaces /etc/init.d/SERVICENAME start | stop ?
If the answers aren't "chkconfig" and "service foo start" then I fear
significant backlash from poor people who actually have to run F-14
systems. We pretty much have t
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.
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
> "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
> "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
> "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
> "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
> "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> 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
> "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
> "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> 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
> "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
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> 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
> "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
1 - 100 of 563 matches
Mail list logo
