Re: [ppc] Default stack size on ppc64
by David Woodhouse
On Tue, 2015-03-24 at 11:35 -0500, Steven Munroe wrote:
> I am not sure how ocaml is generating code for PPC64, you could look in
> to split stack support, but at this time GCC does not implement split
> stack.
... for PPC64.
I wouldn't want to do it in OCaml before it's supported in GCC and the
runtime. But once it *is*, it shouldn't be hard to make OCaml support
it.
It's mostly just a matter of emitting the right instructions in the
function prologue and epilogue, in emit.mlp.
But it does depend on the runtime support for allocating more stack
while not overflowing the 'slop' space on the existing stack, and
linker support for expanding the stack frame size when calling through
to legacy non-split-stack functions, and probably other things. So not
something we'd want to do purely within OCaml.
I'm a little confused about what the problem is, though.
If the compiler is single-threaded, and increasing the stack ulimit
fixes the problem, that implies that the default stack ulimit is less
than the 8MiB-64KiB that it takes to reach the guard page... can that
be right? Richard, what does 'ulimit -s' report *before* you increase
it?
--
dwmw2
9 years, 1 month
[ppc] Default stack size on ppc64
by Richard W.M. Jones
For the OCaml packages on ppc64/ppc64le, we keep having bugs like this
one: https://bugzilla.redhat.com/show_bug.cgi?id=1204876
The OCaml compiler is quite recursive, and so it can easily overflow
the default stack. For reasons that are not entirely clear this
happens only on ppc64/ppc64le (not on x86 or aarch64). Perhaps POWER
stack frames are bigger, or the default stack size is smaller.
One way to "fix" this would be to modify every single ocaml-* spec
file to add:
%ifarch %{power64}
ulimit -s 65536
%endif
However that doesn't fix the problem for people running ocamlopt on
their own programs. The issue was discussed upstream, but upstream
don't want to make the compiler stages less mutually recursive since
(a) it makes the code far more complex and (b) stack memory is just a
special use-case for ordinary memory so why should they?
Could we increase the default stack size on ppc64?
Or are there other alternatives? (I thought briefly about carrying a
downstream compiler patch which does the equivalent of 'ulimit -s 65536'
inside the compiler).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
9 years, 1 month
5tFTW: Fedora conferences this summer, writing release notes, brainstorming a better onramp, and a GSOC reminder (2015-03-25)
by Matthew Miller
Fedora is a big project, and it’s hard to keep up with everything. This
series highlights interesting happenings in five different areas every
week. It isn’t comprehensive news coverage — just quick summaries with
links to each. Here are the five things for March 25th, 2015:
Join us at Flock (and book your hotel now)
------------------------------------------
Every year, we have a big planning and developers’ conference, Flock.
It alternates between Europe and North America, and this time around
will be at the Rochester Institute of Technology in Rochester, New
York, from August 12th to 15th. Flock organizers just announced that
hotel reservations are open, as are talk submission. If you’re an
active contributor or are interested in becoming one, start planning
your trip now!
* http://flocktofedora.org/
* http://fedoramagazine.org/flock-2015-rochester-institute-of-technology/
* http://flocktofedora.net/location/hotels/
* http://flocktofedora.net/submit-a-talk/
Or, come to FUDCon in Pune, India
---------------------------------
In addition to Flock, we also hold annual gatherings in the
Asia/Pacific (APAC) and Latin America (LATAM) regions. These are
FUDCons — Fedora User and Developer Conferences. This year’s APAC
FUDCon will be held in Pune, India from June 26th to 28th.
Talk submissions for this conference are closed and the selection
committee working on choosing the best from over 140 submissions. There
will also be a BarCamp-style track, where sessions will be chosen by
attendees at the conference.
A limited amount of money is available for travel subsidies. See the
FUDCon planning wiki for details.
* https://fedoraproject.org/wiki/FUDCon:Bid_for_Pune_2015
* https://en.wikipedia.org/wiki/BarCamp
* https://fedorahosted.org/fudcon-planning/wiki/FundingRequest
Help with the F22 release notes
-------------------------------
Fedora 22 is almost at the beta stage, with the final release slated
for May. That means it’s time to start writing the release notes, and
Fedora Documentation Project Lead Pete Travis put out a call for
volunteers on the Fedora Join List. As Pete notes, this is a great,
low-barrier way to get involved in Fedora — you don’t need a lot of
prior knowledge, just a little bit of interest in some piece of
software we include.
* https://lists.fedoraproject.org/pipermail/fedora-join/2015-March/000323.html
A more friendly ‘net presence for Fedora
----------------------------------------
This morning, Máirín Duffy led a brainstorming session on the topic of
enabling new contributors, with the eventual goal of developing a
modern Web interface to all aspects of the project for contributors,
both new and already deeply involved. Mo wrote a great summary blog
post afterward, and I highly recommend reading it if you’re interested
in bringing more contributors to Fedora — or just improving your own
workflows and interactions.
* http://blog.linuxgrrl.com/2015/03/25/summary-of-enabling-new-contributors...
Google Summer of Code
---------------------
And finally, a reminder that Fedora is participating in the Google
Summer of Code. The application deadline is March 27 at 19:00 UTC;
please check out Fedora’s GSOC 2015 page if you’re interested in being
involved.
* http://fedoraproject.org/wiki/GSOC_2015
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Fedora Project Leader mattdm(a)fedoraproject.org <http://fedoraproject.org/>
9 years, 1 month
Summary/Minutes from today's FESCo Meeting (2015-03-25)
by Parag Nemade
===================================
#fedora-meeting: FESCO (2015-03-25)
===================================
Meeting started by paragan at 18:00:02 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2015-03-25/fesco.2015-03-...
.
Meeting summary
---------------
* init process (paragan, 18:00:02)
* #1312 F22 System Wide Change: Replace Yum With DNF -
http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF (paragan,
18:01:37)
* AGREED: Replace Yum with DNF in F22+ with plan given in
https://fedorahosted.org/fesco/ticket/1312#comment:29 but complete
it before beta freeze (+5, 0, -0) (paragan, 18:08:23)
* LINK:
https://fedoraproject.org/wiki/Changes/Harden_All_Packages?rd=Changes/Har...
does include -z,now (mitr, 18:23:50)
* AGREED: Revisit Hardening change next week (paragan, 18:29:46)
* #1412 anaconda password change is causing consternation among the user
community please review this policy decision (paragan, 18:30:02)
* LINK: http://pkgs.fedoraproject.org/cgit/anaconda.git/log/?h=f22
(mitr, 18:38:35)
* AGREED: In f22 default back to f21 anaconda password behavior, ask
anaconda developers, fedora-release and releng folks to make this
change happen before Beta freeze. (+5, 0 ,-0) (paragan, 19:13:08)
* ACTION: nirik to work with anaconda developers for anaconda password
policy (paragan, 19:16:01)
* #1374 F22 Self Contained Change:
https://fedoraproject.org/wiki/Changes/DisabledRepoSupport (paragan,
19:16:18)
* AGREED: FESCo approved the DisabledRepoSupport Change (+6, 0, -0)
(paragan, 19:18:13)
* Next week's chair (paragan, 19:18:42)
* Open Floor (paragan, 19:20:56)
Meeting ended at 19:25:02 UTC.
Action Items
------------
* nirik to work with anaconda developers for anaconda password policy
Action Items, by person
-----------------------
* nirik
* nirik to work with anaconda developers for anaconda password policy
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (85)
* mitr (71)
* paragan (67)
* ajax (60)
* rishi (51)
* thozza (29)
* jwb (23)
* zodbot (9)
* drago01 (8)
* jreznik (5)
* Corey84 (3)
* dgilmore (2)
* sgallagh (0)
..
18:00:02 <paragan> #startmeeting FESCO (2015-03-25)
18:00:02 <zodbot> Meeting started Wed Mar 25 18:00:02 2015 UTC. The
chair is paragan. Information about MeetBot at
http://wiki.debian.org/MeetBot.
18:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea
#link #topic.
18:00:02 <paragan> #meetingname fesco
18:00:02 <zodbot> The meeting name has been set to 'fesco'
18:00:02 <paragan> #chair ajax dgilmore jwb mitr nirik paragan rishi
thozza sgallagh
18:00:02 <paragan> #topic init process
18:00:02 <zodbot> Current chairs: ajax dgilmore jwb mitr nirik paragan
rishi sgallagh thozza
18:00:16 <nirik> morning.
18:00:16 <jwb> hi
18:00:20 <paragan> Hi all
18:00:22 <dgilmore> hi
18:00:26 <mitr> Hello
18:00:30 <dgilmore> I have to run in an hour
18:00:35 <thozza> hi
18:00:58 <paragan> we are missing sgallagh_afk and rishi
18:01:26 <paragan> Okay let's start
18:01:37 <paragan> #topic #1312 F22 System Wide Change: Replace Yum
With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
18:01:37 <paragan> .fesco 1312
18:01:40 <zodbot> paragan: #1312 (F22 System Wide Change: Replace Yum
With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF) –
FESCo - https://fedorahosted.org/fesco/ticket/1312
18:02:00 <paragan> dnf developer has given the proposal in
https://fedorahosted.org/fesco/ticket/1312#comment:29
18:02:30 <mitr> +1
18:02:32 * ajax waves
18:02:50 <paragan> anyone have any issues with his proposal?
18:03:03 <thozza> paragan: I'm +1 on it.
18:03:11 <nirik> If the yum/dnf folks agree with that plan of action,
I don't think fesco should stop them... it's a bit worrying that it is
happening now instead of before alpha tho.
18:03:31 <ajax> looks fine to me, +1
18:03:33 <paragan> right this should have happened before alpha
18:04:06 <ajax> i've had fewer issues with dnf in f22 than i've had
with yum, tbh
18:04:42 <drago01> actually yum (as in the tool) should go away the
libary / apis should be there to give users some porting time
18:04:48 <nirik> well, dnf has it's quirks, but it's the future! and
we are just more used to yum's really...
18:04:53 <ajax> i don't think the timing should block the proposal,
given how long its taken to get even to this point.
18:05:00 <drago01> I don't see a reason for a "yum-decprecated"
command but well ...
18:05:02 <ajax> (talk talk talk)
18:05:13 <nirik> right, unless it doesn't land before beta freeze.
18:06:07 <paragan> Proposal: FESCo approves the plan given by dnf
developer for Yum With DNF Change in
https://fedorahosted.org/fesco/ticket/1312#comment:29
18:06:13 <ajax> +1
18:06:16 <ajax> (again)
18:06:18 <nirik> sure, +1
18:06:20 <mitr> +1 again
18:06:21 <paragan> I am +1
18:06:50 <mitr> (And please make sure this is done by beta freeze)
18:07:22 <nirik> asap
18:07:29 <paragan> I see +4 votes
18:07:38 <paragan> any more votes?
18:08:03 <thozza> +1
18:08:23 <paragan> #agreed Replace Yum with DNF in F22+ with plan
given in https://fedorahosted.org/fesco/ticket/1312#comment:29 but
complete it before beta freeze (+5, 0, -0)
18:08:44 <paragan> #topic #1384 F23 System Wide Change: Harden all
packages - https://fedoraproject.org/wiki/Changes/Harden_All_Packages
18:08:45 <paragan> .fesco 1384
18:08:46 <zodbot> paragan: #1384 (F23 System Wide Change: Harden All
Packages - https://fedoraproject.org/wiki/Changes/Harden_All_Packages)
– FESCo - https://fedorahosted.org/fesco/ticket/1384
18:08:56 <ajax> ah, this again
18:09:03 <nirik> fun times.
18:09:10 * nirik reads mitr's comment he just added.
18:09:16 <mitr> Sorry about being so late
18:10:11 <mitr> tl;dr is that I would prefer -z,now on by default (for
non-memory-safe languages at least), but it is not a life-or-death
issue ☺
18:10:56 <ajax> from a security perspective i'd probably agree
18:11:17 <ajax> from a performance perspective i think we really need
to measure the impact and set about mitigation
18:11:32 <ajax> because it's going to be non-zero
18:11:44 <ajax> and at least on (admittedly dumb) workloads, appreciable
18:11:58 <ajax> what i _don't_ see is the feature owners doing that measurement
18:12:29 <ajax> the 'binary compatibility' thing is maybe not the best
way i could have phrased it
18:12:43 <ajax> but basically every other elf system in the world
defaults to -z lazy semantics
18:12:51 <ajax> so... kind of a big change
18:13:13 <mitr> So do we, for anything not compiled within Fedora or
with redhat-rpm-config installed. Sure, that is fuzzy
18:13:44 <mitr> IIRC there were measurements of PIE impact, but not relro.
18:13:55 <ajax> relro is pretty much free at runtime
18:14:10 <ajax> there's one additional mprotect() before you hit main()
18:14:12 <mitr> isn’t relro what requires -z,now
18:14:18 <ajax> nggh
18:14:19 <ajax> so
18:14:22 <ajax> imprecise terms
18:14:51 <ajax> relro on its own just says "here's a section full of
relocations that are const at runtime"
18:15:02 <ajax> in C terms, imagine taking the address of a function
in an external DSO
18:15:13 <ajax> that _could_ be const
18:15:49 <mitr> Sure, I was talking about making the GOT/PLT read only. Sorry.
18:15:56 <mitr> (FWIW the older ticket with the measurements was
https://fedorahosted.org/fesco/ticket/1113 )
18:16:06 <ajax> once you make an executable PIE you create a lot more
relocations
18:16:12 <ajax> and you'd like them to be read-only
18:17:06 <ajax> so that's where -z now comes in, because it moves
those relocations to be approximately as read-only as they'd be were
it not PIE
18:18:26 <paragan> ajax, what I get from the comments is following
proposal, hope that looks okay
18:18:30 <paragan> Proposal: FESCo approves update to Hardening Change
as: default to _hardened_build 0, link executables as -z now and PIE.
The _hardened_build now only affects -z for shared libraries.
18:18:59 <ajax> paragan: "default _hardened_build to undefined" actually
18:19:12 <paragan> #undo
18:19:12 <zodbot> Removing item from minutes: <MeetBot.items.Topic
object at 0x450b8d0>
18:19:16 <nirik> will that require updating all those specs?
18:19:34 <paragan> Proposal: FESCo approves update to Hardening Change
as: default to _hardened_build undefined, link executables as -z now
and PIE. The _hardened_build now only affects -z for shared libraries.
18:20:01 <ajax> nirik: enh, "require" is a funny word there
18:20:15 <ajax> presumably everything that's been "fixed" so far for
this is already doing %undefined _hardened_build
18:20:24 <ajax> so... they'd still be doing that?
18:20:38 <ajax> we can make that mean whatever we want
18:20:43 <mitr> As a packaging matter, I would prefer that if we have
a _hardened_build toggle at all (as opposed to manual overrides), it
should control most or all of the functionality; having a
_hardend_build toggle that controls the comparatively minor relro
aspect but not the major ASLR one would be confusing.
18:20:52 <ajax> the patch i posted makes it mean what paragan proposed there
18:21:02 <mitr> OTOH with the -specs usage we probably do need a toggle
18:21:12 <ajax> the relro thing is effectively already the default anyway
18:21:23 <ajax> like, binutils defaults to it for us, before specs are involved
18:21:26 * nirik was thinking the case where someone did a %if
_hardened_build or whatever, but not sure anyone does that
18:22:29 <jwb> i'm distracted and the proposal reads to me like FESCo
is saying we aren't defaulting to hardened builds, which is what the
feature was requesting. i'll just defer to people paying more
attention than me
18:22:42 * rishi is here
18:22:53 <ajax> jwb: it's hair-splitting
18:22:58 <nirik> the problem is that "hardened_build" is covering
several different things affecting differnt types of builds. ;)
18:23:14 <ajax> the feature was "harden all builds with
position-independent code"
18:23:21 <jwb> originally i thought we approved PIE and PIE only.
nothing to do with -znow
18:23:24 <ajax> is that what they actually meant or not? well, who knows.
18:23:46 <ajax> -znow is orthogonal to pic, so.
18:23:50 <mitr>
https://fedoraproject.org/wiki/Changes/Harden_All_Packages?rd=Changes/Har...
does include -z,now
18:24:15 <ajax> mitr: it says that now, yes. was that because they
intended it to say that, or because they copied in what the macros
_would_ do.
18:24:33 <ajax> (the latter i'm pretty sure)
18:25:09 <ajax> huh, i should give jakub's testcase there a try
18:25:30 <mitr> ajax: You’re right, that table was added later.
18:26:14 <ajax> anyway
18:26:20 <paragan> we are discussing this since last 15 minutes now
18:26:21 <nirik> I'm ok waiting for more test data or just +1ing ajaxs
proposal .
18:26:22 <mitr> ajax: That test case is IIRC a completely artifical
stress test. It doesn’t hurt to know but I wouldn’t consider this a
decisive data point.
18:26:34 <ajax> i've not really had as much time to devote to this as
i'd like due to rhel
18:26:40 <nirik> we just need to make sure we do our changes before
any gcc mass rebuild.
18:26:57 <jwb> are we even going to have time for a mass rebuild before beta?
18:27:04 <nirik> jwb: no no, rawhide.
18:27:06 <mitr> I guess I’ll sum this up and be -1 at this point; the
components that can’t live with -z,now have a workaround, and
optimizing the system for running configure scripts seems dubious.
18:27:06 <ajax> jwb: f23
18:27:09 <jwb> oh, right
18:27:14 <jwb> sorry, as i said, distracted
18:27:43 <ajax> but yeah i'd like to come back to this over the next
week, and i don't think there's any urgency in the f23 schedule yet
18:27:47 <mitr> But I haven’t had any time to actually help with the
workarounds or anything else either
18:28:14 * nirik hasn't noticed any slowness on his rawhide system,
but thats a poor measure. :)
18:28:27 <ajax> there's at least the other buglet mentioned there regarding gnat
18:28:27 <nirik> so, yeah, lets let it cook another week?
18:28:39 <ajax> nirik: +1 defer
18:29:21 <mitr> OK, defer
18:29:26 <ajax> i'm happy to get some more representative data once
i'm out of rhel rebase stress
18:29:28 <paragan> okay let check this next week
18:29:46 <paragan> #agreed Revisit Hardening change next week
18:30:02 <paragan> #topic #1412 anaconda password change is causing
consternation among the user community please review this policy
decision
18:30:02 <paragan> .fesco 1412
18:30:04 <zodbot> paragan: #1412 (anaconda password change is causing
consternation among the user community please review this policy
decision) – FESCo - https://fedorahosted.org/fesco/ticket/1412
18:30:28 <drago01> mitr: "configure scripts" ? wouldn't this affect
anything that execs multiple binaries in a short time like "make" ?
18:30:29 <nirik> so, anaconda can now adjust it's policy...
18:30:34 <paragan> Anaconda developers have added default password
policy in anaconda ->
https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e...
18:30:46 <paragan> Products can implement their own policy by
including a modified copy of
https://github.com/rhinstaller/anaconda/blob/f22-branch/data/interactive-...
in their product.img -- drop it into /usr/share/anaconda/ and it will
overwrite the default.
18:30:48 <mitr> drago01: configure scripts have a much larger
overhead-to-useful-code ratio than compiling
18:31:18 <rishi> mitr: Don't configure scripts also compile random
code to test the compiler?
18:31:18 <mitr> Looking at that interactive-defaults.ks, with the
--strict, it _doesn’t_ actually implement what FESCo has asked for, or
am I mistaken?
18:31:29 <nirik> so, on this one I'd say we should also defer and see
if we can get all the products to agree to as few different policies
as possible?
18:31:29 <drago01> mitr: I can't parse that
18:32:03 <ajax> i kinda don't care what the defaults do if the product
kickstart can override it
18:32:03 <nirik> mitr: we can set whatever policy we want and/or let
products set their own
18:32:11 <drago01> mitr: its not about "configure scripts are
important" but "configure scripts are slow because $foo" ... "other
uses cases do $foo and will be affected to"
18:32:12 <paragan> I am not sure if all product groups should be
following the same password policy.
18:32:12 <drago01> o
18:32:13 <mitr> drago01: Things like (sed 's/^ //') are essentially
millions of instructions to edit a few bytes of memory
18:32:16 <ajax> and there's --nostrict so
18:32:33 <rishi> We are having overlapping discussions. :/
18:32:53 <drago01> rishi: oh sorry didn't notice that the topic changed
18:32:57 <nirik> on configure: benchmarking welcome, we don't need to
discuss that here.
18:32:58 <mitr> nirik: Well, except for non-product?
18:33:29 <drago01> nirik: (you missed the point as well)
18:33:34 <mitr> And fundamentally I very much agree with some people
in that thread, that there should be only one policy. If pwpolicy is
a thing, it should affect the installed system.
18:33:43 <paragan> I see adamw have emailed to all product groups
about this password policy rules.
18:33:59 <rishi> nirik: I spoke with Kalev about the Anaconda change.
It appears that we (as in Workstation) have what we need to relax the
password policy.
18:34:04 <nirik> drago01: sorry...
18:34:05 <rishi> So in that sense the change is OK.
18:34:11 <thozza> I think that what FESCo asked can be implemented in
the products using the change made in anaconda
18:34:16 <mitr> I would say Defer, but the beta freeze is next Tuesday.
18:34:21 <nirik> rishi: sure, but if we can get everyone to agree to
ONE POLICY thats better. ;)
18:35:04 <jwb> i don't think that's realistic
18:35:09 <rishi> nirik: Agreed. But strictly speaking that is outside
the scope of what we asked from Anaconda.
18:35:15 <jwb> cloud wants to use ssh keys and not passwords at all
18:35:15 <nirik> sure.
18:35:35 <nirik> cloud doesn't run the installer...
18:35:47 <thozza> can we use the same policy as for F21 for all products in F22?
18:36:03 <jwb> by default?
18:36:07 <jwb> maybe
18:36:10 <nirik> if we can get them all to agree.
18:36:16 <rishi> Now the ball is in the WGs' court, not Anaconda's.
18:36:33 <jwb> but getting it coordinated and approved by Server and
Workstation before then seems a stretch
18:36:35 <thozza> I thought we want to fall back to the F21 state for F22
18:36:43 <thozza> until some policy is prepared
18:36:49 <nirik> jwb: adamw has sent out an email to try and do
this... it might well be possible
18:37:00 <jwb> what was asked them to do was allow the 'double done
click' functionality
18:37:00 <nirik> thozza: all we agreed to was to readd the 'double done'
18:37:06 <mitr> Proposal: go back to anaconda and ask them to
implement exactly what
https://fedorahosted.org/fesco/ticket/1412#comment:37 has asked for;
AFAICS that hasn’t happened and _we don’t have time_.
18:37:07 <jwb> afaik, they didn't do that and did this instead?
18:37:13 <thozza> nirik: sure
18:37:42 <paragan> afaik they don't want to change upstream code
18:37:44 <mitr> We can continue to have the pwpolicy discussion for
F23 of course.
18:37:53 <nirik> mitr: ?
18:37:54 <thozza> mitr: I think it is possible also with the change they made
18:38:04 <mitr> paragan: so IIRC the plan was to patch it in f22,
which, looing at git log, didn't happen.
18:38:22 <nirik> They said that they would re-add it, but in a local
to fedora way.
18:38:30 <nirik> that upstream defaults would not change
18:38:35 <jwb> perhaps there's a subtle language issue here
18:38:35 <mitr> http://pkgs.fedoraproject.org/cgit/anaconda.git/log/?h=f22
18:38:35 <nirik> thats what this is?
18:38:36 <paragan> right instead they given choices to implement
password policies
18:38:58 <jwb> they said it would have to be carried as a patch.
nobody ever said who was creating said patch
18:39:14 <ajax> childish.
18:39:25 <ajax> like the world's stupidest game of "i'm not touching you!"
18:40:05 <jwb> could be they just forgot too
18:40:13 <thozza> can we just use what anaconda is using except
--strict (use --nostrict) instead which would bring back the double
click
18:40:16 <thozza> ?
18:40:18 <nirik> anyhow...
18:40:49 <mitr> Sorry, the git log above is not really representative
because anaconda is just rebasing tarballs
18:40:50 <paragan> so what we want to propose here, fallback to old
double click password acceptance or implement password policies
18:41:19 <thozza> paragan: the double click can be implemented using --nostrict
18:41:24 <nirik> I'm not sure of the details (we need sgallagh_afk who
has actually tested stuff for server), but I would say:
18:41:50 <nirik> set a default policy back to the f21 one, working
groups can override
18:42:14 <thozza> nirik: that's what I said basically... so I agree
18:42:28 <nirik> but the ramp is short.
18:42:31 <rishi> Ok, so pwpolicy has --nostrict flag.
18:42:34 <mitr> Proposal: anaconda to switch the default as requested
previously for F22, for all products and non-products, using whatever
mechanism they find appropriate, in whatever package they find
appropriate, by F22 beta freeze.
18:42:46 <paragan> I am not sure if the rules they have given in that
commit, can be used to created f21 policy by product groups
18:42:46 <nirik> mitr: -1
18:43:05 <mitr> I'm not excited to go looking for new ways to package
that kickstart in $something now, and someone to do it.
18:43:25 <nirik> mitr: that ordering people to do work for us where we
know they will not be thrilled to do so. Setting up for failure.
18:43:37 <nirik> sgallagh was testing this yesterday for server.
18:43:51 <rishi> nirik: Agreed.
18:44:04 <nirik> but the f22 build doesn't have this yet.
18:44:08 <mitr> nirik: We have already done that three weeks ago; if
we do it at all, then we need to follow up or enforce. Or we can just
plain stop doing that and make these meetings shorter :)
18:44:10 <rishi> mitr: I am reading
https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e...
...
18:44:10 <nirik> and rawhide was crashing on him
18:44:27 <rishi> mitr: It seems we have the necessary framework to
restore the F21 behaviour.
18:44:35 <nirik> right.
18:44:47 <mitr> rishi: Framework, perhaps. Actual packaging desiign,
people to impelment such design, and _time_, not. The freeze is on
Tuesday.
18:44:48 <jreznik> yep
18:45:11 <jreznik> but still doable
18:45:29 <jreznik> and everything is better than double click from UX
perspective
18:45:39 <nirik> we are not getting rid of double done.
18:46:17 <rishi> mitr: We can just ask the WGs to use a policy that is
exactly the same as the F21 behaviour.
18:46:22 <paragan> hm so defer this ticket again?
18:46:31 <mitr> paragan: No time
18:46:32 <jwb> nirik, uh...
18:46:37 <jwb> it's already gone
18:46:48 <jreznik> it's gone for good
18:46:51 <paragan> right beta freeze is coming
18:46:53 <jwb> we asked for it to be added back. it isn't added back
18:46:56 <jwb> so?
18:46:57 <rishi> jwb: Gone? Double done is gone?
18:46:58 * nirik sighs.
18:47:00 <nirik> no.
18:47:12 <rishi> So what is this --nostrict thing then?
18:47:14 <nirik> It is not added back currently.
18:47:18 <mitr> rishi: Yes it is gone in the configuration that is
being used at this very moment.
18:47:22 <nirik> however, they have given us a way to do so
18:47:35 <rishi> mitr: nirik: Right.
18:47:36 <nirik> it's up to us to do so by adding a small %anaconda
section to the kickstarts we use
18:47:52 <nirik> or I suppose yell at them and ask them to scrap all
this and just re-add double done
18:47:55 <rishi> So we can just use a config that mimics F21.
18:48:18 <nirik> rishi: yes...
18:48:51 <rishi> Basically, I don't want to antagonize the Anaconda
folks too much.
18:48:51 <nirik> --nostrict --minlen=6 --minquality=1 --nochanges --emptyok
18:49:40 <paragan> I still not sure what are we concluding here
18:49:51 <rishi> As long as we can reasonably do whatever we want,
which at this point is getting the F21 behaviour back.
18:49:58 <rishi> nirik: Right.
18:50:33 <thozza> can we ask them to carry the patch for the default
configuration of options they introduced for F22?
18:50:42 <thozza> to mimic the F21 behavior...
18:50:46 <thozza> I mean anaconda
18:51:17 <thozza> why should we ship it in a separate package?
18:51:19 <rishi> And on top of that, ask the WGs to not change the
behaviour because now they can do that in their kickstart.
18:51:25 <thozza> sure
18:51:31 <nirik> rishi: why?
18:51:52 <nirik> thozza: we could ask, but they didn't want to change
the defaults... so not sure they would be receptive.
18:51:57 <mitr> rishi: That seems unnecessary.
18:52:02 <rishi> Umm... don't we want F22 to retain the F21 behaviour?
18:52:33 <rishi> Atleast that is what
https://fedorahosted.org/fesco/ticket/1412#comment:37 says.
18:52:38 <jwb> nirik, i see. i was confused because the UI work was
done in a commit before the one bcl linked to
18:52:40 <nirik> all we wanted was the double done back. ;)
18:52:51 <mitr> nirik: Well #1191842 is a beta blocker
18:52:57 <thozza> nirik: they can keep the defaults in rawhide and upstream
18:53:05 <nirik> mitr: good point.
18:53:45 <mitr> nirik: As a matter of principle, “upstream disagrees”
is no way to make a consistent distribution. I just don’t buy that at
all.
18:53:46 <nirik> thozza: well, we could ask.
18:53:49 <rishi> nirik: Yeah, but now we have the possibility that a
product change the policy to something else.
18:54:05 <rishi> At the end of the day, the question is: "what does
the user see".
18:54:31 <mitr> rishi: If a product thinks they have a good basis for
a different policy, and enough time and interest to implement this, I
don’t currently see a good reason to stop them.
18:54:52 <nirik> mitr: well, this is a bigger conversation really... I
mean when we have a upstream that doesn't do what we want, normally we
have a set of maintainers that adjusts upstream for us, but we really
don't have that in some cases.
18:54:55 <rishi> mitr: Ok., so in that case, everything is perfect now. No?
18:55:21 <mitr> rishi: No becaususe if a product doesn't think so or
doesn’t have time and interest we are in a broken situation.
18:56:00 <rishi> mitr: Can't the product just use:
18:56:01 <rishi> --nostrict --minlen=6 --minquality=1 --nochanges --emptyok
18:56:06 <rishi> as nirik said ?
18:56:20 <nirik> sure, but then all the nonproduct things will still
have the anaconda defaults.
18:56:22 <mitr> So…? Do we have a volunteer to figure out what
kickstarts, where and how need adjusting, and do so, so that I can +1
them and we can move on? If not, please let
18:56:28 <mitr> ’s kick this back to anaconda.
18:56:35 <mitr> Or are there any other options we could be pursuing?
18:56:37 <rishi> nirik: You mean the spins?
18:57:00 <nirik> spins, atomic images, arm appliances, the other
billion things we are making now.
18:57:05 <nirik> netinstall isos
18:57:22 <rishi> nirik: Ok. I see the point now.
18:57:30 <thozza> is there any common package/place to include the
defaults? I mean common for all spins, etc...
18:57:37 <nirik> mitr: what exactly do you want to ask anaconda folks?
can you form a proposal?
18:57:38 <rishi> In that case, I think it is reasonable to ask
Anaconda to change the default to mimic F21.
18:57:42 <ajax> spin-kickstarts.git, yes
18:57:59 <nirik> many of the items in the spin-kickstarts use common
stuff and include...
18:58:01 <mitr> nirik: I have formed two above; I suppose the second
one, perhaps toned down by someone who is not as annoyed as I am.
18:58:20 <rishi> Unless we can osomehow verride it for the spins,
atomic images, etc..
18:58:34 <nirik> I don't know enough about the setup to say.
18:58:44 <nirik> as I noted sgallagh was looking into it.
18:58:45 <mitr> thozza: IMHO libpwquality would be appropriate but
that is again getting into design discussions we don’t have time for.
18:59:00 <paragan> Should we wait to see what product WG's are
concluding on how to use this new password policy or we want to decide
on this today?
18:59:18 <mitr> paragan: Wait till when?
18:59:30 <nirik> I am ok waiting a week to see if we can come up with
something based on this anaconda framework.
18:59:34 <paragan> not sure say next week
18:59:34 <mitr> nirik: for the record:
18:59:36 <mitr> Proposal: anaconda to switch the default as requested
previously for F22, for all products and non-products, using whatever
mechanism they find appropriate, in whatever package they find
appropriate, by F22 beta freeze.
18:59:44 <mitr> paragan: The freeze is Tuesday next week, again.
18:59:54 <nirik> yes, but as you noted this is a blocker bug.
18:59:54 <ajax> mitr: +1
19:00:00 <thozza> mitr: +1
19:00:09 <mitr> +1 for the record
19:00:10 <rishi> paragan: As far as I can see this isn't about the WGs.
19:00:17 <thozza> they now have the mechanism they implemented, so
they can use it :)
19:00:29 <rishi> It seems to be about what the non-product things that
we have are going to use.
19:00:46 <rishi> mitr: +1
19:00:53 <paragan> rishi, I just thought we are not finding common
proposal so hear what WG will say
19:01:40 <paragan> mitr, defaults to f21 password policy in your proposal?
19:02:16 <mitr> paragan: To be more precise, s/as requested previously
for F22/& in https://fedorahosted.org/fesco/ticket/1412#comment:37/
19:02:22 <rishi> paragan: Well, right now, all the WGs can either
decide to use the F21 policy, or use their own (mitr and nirik sounded
happy about that). The problem seems to be that the non-products don't
have a way to override the Anaconda default, which is not what the F21
policy was.
19:02:45 * nirik is again hobbled by not having played with this stuff.
19:02:54 <nirik> it could well be that they can override too in their
kickstarts, etc.
19:02:57 <mitr> rishi: For the record I am _not_ happy about what the
pwpolicy thing does, but that can be easily enough adjusted for F23
19:04:06 <mitr> (to be specific, the kickstart directives should IMHO
affect the installed system)
19:04:07 <rishi> mitr: Out of curiosity, what part of the pwpolicy
thing do you not like?
19:04:12 <mitr> ^^
19:04:18 <nirik> so, that means we want --nostrict to be default in
f22 anaconda... right?
19:04:45 <paragan> I am not sure if anaconda developers will be agree
to provide double done as they have given way to implement own
policies
19:04:45 <thozza> nirik: right
19:04:49 <jreznik> and it does not have to be implemented by anaconda
but other teams
19:04:52 <mitr> nirik: As far as my proposal above, I wanted to leave
the implementation details up to implementers.
19:04:59 <mitr> nirik: But yes, it seems so.
19:05:02 <jwb> paragan, they provided double done via --nostrict
19:05:34 <mitr> (We are going in this circle for the 3rd or 4th time,
aren’t we?)
19:05:35 <rishi> mitr: The kickstart directives don't affect the
installed system? Are you talking about things like
gnome-initial-setup or gnome-control-center which have their own
password UI?
19:05:36 * nirik also notes it could be implemented by
fedora-release-nonproduct for nonproducts perhaps. But again, I have
not had time to look at implementation details
19:05:52 <thozza> mitr: it seems so :-(
19:06:12 <ajax> i'm trying very hard not to.
19:06:15 <mitr> rishi: AFAICS they affect _nothing_; and they should
affect _everything_ the same way the auth directive does.
19:06:19 <rishi> I guess we should first figure out if the
non-products can override the default.
19:06:24 <nirik> +0 on the proposal from me, as I don't know that
anaconda would be the best place to make this change.
19:06:26 <rishi> That should break the circle. :)
19:06:40 <thozza> we have +4 on mitr's proposal
19:06:53 * rishi re-reads the proposal
19:07:02 <mitr> nirik: The proposal is not claiming that anaconda is
the best _place_, only the best _people_ to make it.
19:07:06 * Corey84 joins rishi
19:07:08 <thozza> nirik: it does not say it has to be anaconda
19:07:09 <thozza> ;)
19:07:20 <nirik> mitr: well, I am not sure thats even the case.
19:07:31 <mitr> nirik: That’s fair.
19:07:34 <nirik> if we can make this in fedora-release* the
maintainers there would be
19:07:37 <rishi> "whatever package" and "whatever mechanism" seems
like the operative words. :)
19:07:53 <Corey84> given the issues anaconda has been facing as of
late I say its not but willing to help change that
19:08:28 <nirik> mitr: ok, so 'anaconda' in your proposal was the
software, not the anaconda developers specifically?
19:08:53 <mitr> nirik: Sorry, it should have been the developers.
19:08:57 <paragan> Proposal: Ask anaconda developers to provide patch
that will give F21 password double done policy in F22 for all products
19:09:05 <Corey84> i'd go +1 if that interpration is correct
19:09:07 <paragan> does above looks similar to mitr proposal
19:09:14 <rishi> nirik: We can add a "whoever" in there for all I care.
19:09:16 <mitr> paragan: s/provide and apply/
19:09:24 <jwb> Corey84, please don't vote if you are not a FESCo member
19:09:40 <rishi> paragan: Your proposal doesn't cover the non-products.
19:10:26 <mitr> Rewording for clarity:
19:10:28 <mitr> Proposal: Ask anaconda developers to switch the
default as requested previously for F22 in
https://fedorahosted.org/fesco/ticket/1412#comment:37 , for all
products and non-products, using whatever mechanism they find
appropriate, in whatever package they find appropriate, by F22 beta
freeze.
19:10:29 <nirik> proposal: In f22 default back to f21 anaconda
password behavior, ask anaconda developers, fedora-release and releng
folks to make this change happen before Beta freeze.
19:10:34 <paragan> Okay +1 to mitr proposal then
19:11:03 <rishi> I like nirik 's more.
19:11:07 <paragan> actually I was looking for simple text
19:11:17 <mitr> nirik: +1 I guess, it’s a collective body/collective
responsibility either way.
19:11:20 <paragan> I like nirik's proposal
19:11:25 <rishi> Because it includes more people than just "anaconda
developers".
19:11:31 <ajax> +1 to whatever makes this a thing we're not talking
about anymore tbh
19:11:38 <rishi> ajax: Yeah.
19:11:38 <nirik> ajax: :)
19:11:54 * rishi hands out a few +1s to both nirik and mitr
19:12:02 <paragan> I see we are about to get nirik proposal approved
but who is going to work on this?
19:12:09 <thozza> mitr: +1
19:12:21 <nirik> I can try and shepard it...
19:12:36 <nirik> hopefully sgallagh has already done the heavy lifting.
19:12:42 <nirik> do we want to allow products to override tho?
19:13:08 <paragan> #agreed In f22 default back to f21 anaconda
password behavior, ask anaconda developers, fedora-release and releng
folks to make this change happen before Beta freeze. (+5, 0 ,-0)
19:13:34 <mitr> nirik: In principle, I think so; at this moment, I’d
say preferably only if it is done by Beta freeze.
19:13:35 <nirik> proposal: products may override password policies
from the default.
19:13:48 <nirik> mitr: good point...
19:14:21 <rishi> nirik: I am leaning towards "no" to that since it is
quite late, but if some WG really wants something else, then it should
be b y Beta freeze.
19:14:31 <mitr> nirik: +1 if that needs to be voted on; IIRC
configuration divergences have always been fair game, though I am not
sure whether we have an explicit decision to that effect
19:14:42 <nirik> ok, like I said sgallagh was working on it, so he may
have something for server by tuesday
19:14:59 <nirik> mitr: also good point. so, lets just say they can and move on.
19:16:01 <paragan> #action nirik to work with anaconda developers for
anaconda password policy
19:16:09 <rishi> nirik: mitr: FWIW when I tried to relax the policy in
gnome-control-center, I was hampered by pam. So not sure how easily a
product can use its own policy in practice.
19:16:18 <paragan> #topic #1374 F22 Self Contained Change:
https://fedoraproject.org/wiki/Changes/DisabledRepoSupport
19:16:19 <paragan> .fesco 1374
19:16:20 <zodbot> paragan: #1374 (F22 Self Contained Changes) – FESCo
- https://fedorahosted.org/fesco/ticket/1374
19:16:25 <mitr> rishi: g-c-c should not have its own policy at all, it
should be in pwquality.
19:16:27 <nirik> rishi: well, for install... but yes, there's still
nothing unified. ;(
19:16:46 <nirik> +1 this self contained change.
19:16:55 <paragan> +1
19:16:56 <mitr> +1 to the disabled-repo support (and annoyed about the
packaging tools split)
19:17:24 <thozza> +1
19:17:24 <ajax> +1 to this change
19:17:54 <paragan> cool
19:17:58 <rishi> +1
19:18:13 <paragan> #agreed FESCo approved the DisabledRepoSupport
Change (+6, 0, -0)
19:18:39 <paragan> I think we are done with tickets :)
19:18:42 <paragan> #topic Next week's chair
19:18:42 <paragan> any volunteer? :)
19:18:55 <ajax> have we rotated everyone through yet?
19:20:17 <mitr> I can do it next week.
19:20:38 <paragan> mitr, thanks
19:20:45 <paragan> #note mitr to chair next week
19:20:56 <paragan> #topic Open Floor
19:20:56 <paragan> anything for open floor?
19:21:20 <ajax> nothing from me.
19:21:26 * nirik has nothing
19:23:18 <paragan> If there is nothing to discuss then I'll end the
meeting in a minute
19:25:02 <paragan> thanks everyone for having this meeting.
19:25:02 <paragan> #endmeeting
9 years, 1 month
unzip - support of segmented archives - look for volunteers for testings
by Petr Stodulka
Hi folks,
I work on patch for support of segmented archives on unzip. It's created
alpha patch, which will be modified in future
and probably (that's perhaps certainty ) it still contains bugs. However
some testing should helps next devel, so if someone works with *.zip
multi-disk archives and want to try/test this new feature
a) here you can download scrach-build which you want - I did build only
for F21 now (unzip-6.0-22.fc21.src.rpm)
http://koji.fedoraproject.org/koji/taskinfo?taskID=9319882
(if you want check code direct in repository, patch is inside branch
pstodulk_segment)
b) or you can test upstream version:
$ wget http://antinode.info/ftp/info-zip/unzip610c17s.zip
$ unzip unzip610c17s.zip
$ cd unzip610c17s
$ make -f unix/Makefile -j5 CC=cc PROD=compiled_unzip
LOCAL_UNZIP=-DNO_EXCEPT_SIGNALS LFLAGS2=-L. generic
$ cd compile_unzip
- and try unzip your multidisk archive (is expected *.zip file as input!
and all segments must be in the same directory!)
- multi-volume archives are not supported now (with different names,
e.g.: main.zip not_main.z01 )
You could still see warning (or even error) messages about missing bytes
and unssuported multi-disk archives.
Exit code could be wrong. This all you can ignore now, fix of these
problems is in todolist for next month.
Important are unziped output files, that should be correct.
-> are files really OK? -> Get you same output as you get by old method
of concatenation or
with pretreatment by "zip -FF segmented_archive.zip --out
complex_archive.zip"?
Or you can use for unzip "-t" option for test of archive. Whatever you
want try.
When you know that archive is ok and you get wrong output, please write
me and add link to archive
if it is publicly accessible on the internet or write how can be create it.
(or attach it if it is small).
If you want, you can post same tests for this test-suite:
https://github.com/pirat89/zip-tests
Thanks to all who will help with tests :-)
Regards,
Petr
9 years, 1 month
Re: [ppc] Default stack size on ppc64
by Richard W.M. Jones
On Tue, Mar 24, 2015 at 11:35:30AM -0500, Steven Munroe wrote:
> On Tue, 2015-03-24 at 12:19 +0000, Richard W.M. Jones wrote:
> > For the OCaml packages on ppc64/ppc64le, we keep having bugs like this
> > one: https://bugzilla.redhat.com/show_bug.cgi?id=1204876
> >
> > The OCaml compiler is quite recursive, and so it can easily overflow
> > the default stack. For reasons that are not entirely clear this
> > happens only on ppc64/ppc64le (not on x86 or aarch64). Perhaps POWER
> > stack frames are bigger, or the default stack size is smaller.
> >
> The default thread stack is 8MB-64KB plus a 64KB guard page. PPC uses a
> 64K default page size.
>
> So there are two possible problems:
>
> 1) running into the guard page for a single thread.
> 2) the sum of all thread stacks exceeds the ulimit -s
The OCaml compiler is single threaded AFAIK.
> If changing the ulimit -s solves the problem the sum of all thread
> stacks has exceeded the ulimit.
>
> If in cases where increasing the ulimit -s to unlimited does no help
> then you have at least one thread that has overflowed the default stack.
>
> Power has lots of registers (32x64b GPRs + 32x64b FPRs + 32x128b VRs) so
> we are likely to need a bigger stack frame at each level. The minimums
> are 112 bytes for ELF V1 ABI (PPC64BE) and 48 for ELF V2 ABI (PPC64LE),
> but any interesting function will need additional space to spill
> non-volatiles across function calls and store any local variables.
>
> You (ocaml runtime) can control the stack size on a per thread basis via
> pthread_attr_setstack().
>
> I am not sure how ocaml is generating code for PPC64, you could look in
> to split stack support,
OCaml uses its own code generator. However the description of
-fsplit-stack from GCC sounds interesting. Are there any more details
of how exactly it works? Does it catch the segfault from hitting the
guard page and do something clever?
> but at this time GCC does not implement split
> stack.
Did you mean "does implement"? GCC 5 documents it at least ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
9 years, 1 month
New notifications
by Jerry James
Changing the subject to something more appropriate.
On Tue, Mar 24, 2015 at 9:35 AM, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
> We have changed the way notifications are sent to the scm-commits mailing list.
> Before we had notification sent by the git hook, by pkgdb, by X Y and Z.
> With the move to production of FMN a little while ago, we had in mind of
> switching the notifications to scm-commits to use this system, and over the last
> hour we have done it.
>
> So emails sent to scm-commits now come from FMN, allowing, for example,
> consolidation of the pkgdb notifications.
>
> So I guess your email filter might have to be adjusted for this change.
Okay, I've got 3 filters set:
- Mentions of my @username
- Events on packages that I own
- Events referring to my username
But I'm getting LOTS of notification emails that, as far as I can see,
have nothing to do with my username or any package that I own. I
don't understand how to adjust my filters to make those stop.
Furthermore, there is still the issue that the link at the bottom of
the email notifications is not useful. Clicking on those links just
returns an HTTP 403, which is not helpful. Trying to dissect them
with my apparently uninformed brain is not teaching me anything. What
am I supposed to be able to glean from those links? I need a Rosetta
Stone....
Thanks,
--
Jerry James
http://www.jamezone.org/
9 years, 1 month
Lazarus broken for fedora 22
by Heiko Adams
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
lazarus and *all* binaries build with lazarus are broken (they don't
start) for Fedora 22 and the maintainer seems to be unresponsive. So
could someone else take a look at that bug and maybe update lazarus to
more recent version which fixes that issue?
The problem has already been reported to bugzilla
(https://bugzilla.redhat.com/show_bug.cgi?id=1203118) but hasn't been
any repsonse.
- --
Regards,
Heiko Adams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVEpO1AAoJED6DRcV6KbgxxWYP/3MGy4GlbIUbK5O4UHrAQRXo
SPAyBRN7p/UcNOfh5Opkr/q97IVYl7b++uOvaKm3kj/fbCPV9fJ+Szf9zSVbakLj
UmI2vlbxBUJFZU6gDbyFSNq7u9F6QPWGDXY38ynsQkE6XSqgzqqcv+MUWcsQBD1F
Or4YloSwcGQLvGEBOKM0g+x36tkED/k+1b0WRFoWEa4BDf6C7sMYu/WQpWETnRfr
yiVf+dYhqzF2JS8p+MHU7ymdWKV6CgfMCL4sIeM/mmFSLC9EPBDfEqqEOE6l8a/P
a8vg/vUMhsixa+ThYWl30zQUD4QsuAIp+2QGt8oSrpkL8npeSv/bH62xjFaruTZY
bY3BrLiA6g8vv5AQKRySgUom8hjiP/3r2g8t2CO1gkqjg4gk9ndNcSo6M4d2R24u
6RJwfGd512Wv+7A+UKarAoHnse7BNVhGu/0mgYk3YTuzjVipDGP/de+FwnDTtSUB
BNEEmlNTUo0KTUuPoorYjMo6P6m/z+6N+ns/hJDvH2lBz2+oy8PQHx5Ss+pWwAoY
bn36bB8HXTTCVRCUG7GOzr3Sfy0QKzeNQDSYl6/i4+IO8TYX7Y57gf/JjCsO8suF
T3dhX2N+Z5jh1/UhtZ6D67FXcggfg8YDZaqMvgQUnVgO6yQDwgLUAm1hAXuNj/B+
mI5vMNa6cdHNRBCizzDI
=ypHF
-----END PGP SIGNATURE-----
9 years, 1 month
"dnf search" as braindead as "yum search"
by Michael Schwendt
# dnf search libtoolize
Using metadata from Sat Mar 21 15:38:26 2015
============================= Matched: libtoolize ==============================
libedit.x86_64 : The NetBSD Editline library
libedit.i686 : The NetBSD Editline library
D'oh!
It's a false positive, because the word "libtoolized" is found in
the package description of "libedit". The package "libtool" is not
found, because "dnf search" doesn't search filelists by default.
A highly questionable decision.
9 years, 1 month