Re: captive portal implementation found lacking

[Adam Williamson]

On Thu, 2015-03-26 at 00:08 -0400, Rich Mattes wrote:
> On 03/25/2015 09:52 PM, David Airlie wrote:
> > 
> > Hey devs,
> > 
> > So Simo wanted to explode so I've tried to distill down the issues 
> > we saw:
> > 
> > a: you can't uninstalled the config connectivity package from 
> > workstation without losing gnome-shell and gdm.
> > https://bugzilla.redhat.com/show_bug.cgi?id=1205963
> 
> 
> I re-assigned that bug to gnome-shell, which is where the dependency 
> is  actually coming from.

It's already gone in F22; I may have steered people a bit wrong in 
IRC, because I checked on F22, where gnome-shell does not have that 
dep, but fedora-release-workstation does. In F21, indeed, Shell has 
the dep.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: captive portal implementation found lacking

[Rich Mattes]

On 03/25/2015 09:52 PM, David Airlie wrote:


Hey devs,

So Simo wanted to explode so I've tried to distill down the issues we saw:

a: you can't uninstalled the config connectivity package from workstation 
without losing gnome-shell and gdm.
https://bugzilla.redhat.com/show_bug.cgi?id=1205963



I re-assigned that bug to gnome-shell, which is where the dependency is 
actually coming from.  There's also a dependency in 
fedora-release-workstation, which I think is more defensible but is able 
to be worked around while still keeping gnome installed (e,g. by 
replacing fedora-release-workstation with fedora-release-nonproduct).




this seems sub optimal.

b: the feature is over zealous in its letting you know it can't find fp.org



Agreed.  There's a FESCo discussion and ruling on the feature at [1] 
which kind of fizzled out.  I think it's worth following up there and 
through the aforementioned bug to follow through with the FESCo decision 
"AGREED: Ask Workstation to rethink how to pull the package in with the 
goal of easily enabling people to opt out (+5, 0, -0) (sgallagh, 
17:47:38)"


Rich

[1] https://fedorahosted.org/fesco/ticket/1337
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Captive portal detection on wired connections - bug or feature?

[Kevin Fenzi]

On Wed, 25 Mar 2015 22:26:56 -0400 (EDT)
Paul Wouters  wrote:

> On Wed, 25 Mar 2015, Adam Williamson wrote:
> 
> > Lots of people have been seeing it, it may be related to some issues
> > with the Fedora infrastructure this afternoon (the check works by
> > trying to contact a Fedora server).
> 
> I've seen them regularly in the last few hours but I'm on hotel wifi,
> so it could also be just crappy wifi.
> 
> The dnsec-trigger package which I'm also running also has hotspot
> detection, using http://hotspot-nocache.fedoraproject.org/ which
> does not seem to cause tehse false positives.

This was most likely caused by some issues with out proxy servers this
evening. We were adding 3 new proxy servers into the rotation and there
were some config issues with some of them. ;( 

This would have only affected some folks in North America sporadically,
(when they happened to hit a proxy that wasn't working right) not
everyone. 

Sorry this happened, everything should be back to normal now. 

kevin


pgpS_Iiaqx5sn.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Captive portal detection on wired connections - bug or feature?

[Paul Wouters]

On Wed, 25 Mar 2015, Adam Williamson wrote:


Lots of people have been seeing it, it may be related to some issues
with the Fedora infrastructure this afternoon (the check works by
trying to contact a Fedora server).


I've seen them regularly in the last few hours but I'm on hotel wifi,
so it could also be just crappy wifi.

The dnsec-trigger package which I'm also running also has hotspot
detection, using http://hotspot-nocache.fedoraproject.org/ which
does not seem to cause tehse false positives.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Captive portal detection on wired connections - bug or feature?

[Alexander Ploumistos]

On Thu, Mar 26, 2015 at 4:06 AM, Adam Williamson  wrote:

> Lots of people have been seeing it, it may be related to some issues
> with the Fedora infrastructure this afternoon (the check works by
> trying to contact a Fedora server).
>

That much I gathered, but when I first read about the captive portal
detection feature, I thought it was supposed to work only with wireless
connections, though I guess it would make sense to check with all
interfaces.

Can it be disabled for a particular interface/connection though? I am being
bombarded with pop-ups as I am trying to write this...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Captive portal detection on wired connections - bug or feature?

[Adam Williamson]

On Thu, 2015-03-26 at 03:59 +0200, Alexander Ploumistos wrote:
> During the last hour, I got three pop-ups on my workstation (which 
> is connected over Ethernet) with blank windows and a title that read 
> "Captive
> portal". Two of them turned to the gnome.org home page, while the 
> other one
> just disappeared.
> 
> Is this supposed to happen or do I need to file a bug report?

Lots of people have been seeing it, it may be related to some issues 
with the Fedora infrastructure this afternoon (the check works by 
trying to contact a Fedora server).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Captive portal detection on wired connections - bug or feature?

[Alexander Ploumistos]

During the last hour, I got three pop-ups on my workstation (which is
connected over Ethernet) with blank windows and a title that read "Captive
portal". Two of them turned to the gnome.org home page, while the other one
just disappeared.

In my journal I have this sort of errors:
Mar 26 03:39:36  NetworkManager[1006]:   Connectivity check
for uri 'https://fedoraproject.org/static/hotspot.txt' returned status '403
Forbidden'; assuming captive portal.
Mar 26 03:39:36  NetworkManager[1006]:   NetworkManager
state is now CONNECTED_SITE
Mar 26 03:39:36  NetworkManager[1006]:   Connectivity check
for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Error
performing TLS handshake: An unexpected TLS packet was received.'.
Mar 26 03:39:40  NetworkManager[1006]:   NetworkManager
state is now CONNECTED_GLOBAL
Mar 26 03:39:46  NetworkManager[1006]:   Connectivity check
for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Error
performing TLS handshake: An unexpected TLS packet was received.'.
Mar 26 03:39:46  NetworkManager[1006]:   NetworkManager
state is now CONNECTED_SITE
Mar 26 03:39:48  NetworkManager[1006]:   Connectivity check
for uri 'https://fedoraproject.org/static/hotspot.txt' returned status '403
Forbidden'; assuming captive portal.
Mar 26 03:39:49  NetworkManager[1006]:   NetworkManager
state is now CONNECTED_GLOBAL
Mar 26 03:39:55  NetworkManager[1006]:   Connectivity check
for uri 'https://fedoraproject.org/static/hotspot.txt' returned status '403
Forbidden'; assuming captive portal.
Mar 26 03:39:55  NetworkManager[1006]:   NetworkManager
state is now CONNECTED_SITE
Mar 26 03:39:56  NetworkManager[1006]:   NetworkManager
state is now CONNECTED_GLOBAL

Is this supposed to happen or do I need to file a bug report?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

captive portal implementation found lacking

[David Airlie]

Hey devs,

So Simo wanted to explode so I've tried to distill down the issues we saw:

a: you can't uninstalled the config connectivity package from workstation 
without losing gnome-shell and gdm.
https://bugzilla.redhat.com/show_bug.cgi?id=1205963

this seems sub optimal.

b: the feature is over zealous in its letting you know it can't find fp.org

you are sitting there typing, you get a full screen window with some GNOME 
stuff on it, with no warning
whatsoever. Has your local network crashed? no, fedoraproject.org webserver got 
outaged or the route
failed over, but you don't get that info, you get a full screen GNOME page.

maybe just indicate in the top corner or pop up a status bar for someone to 
click on to get the 
full screen page, my desktop is not a tablet

maybe we should be trying to connect to more than one site, and maybe some 
sites on different networks.

Otherwise I think this feature is a bit half baked as is.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ppc] Default stack size on ppc64

[Richard W.M. Jones]

On Wed, Mar 25, 2015 at 08:03:31PM +, David Woodhouse wrote:
> On Wed, 2015-03-25 at 19:45 +, Richard W.M. Jones wrote:
> > On Wed, Mar 25, 2015 at 06:30:25PM +, David Woodhouse wrote:
> > > 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...
> > 
> > Just so I'm clear, is the stack supposed to grow down automatically
> > (ie. does the stack automatically use MAP_GROWSDOWN), or is OCaml
> > supposed to do something when the stack hits the guard page?
> > 
> > I guess it's also possible that an OCaml stack frame is so big that it
> > skips the guard page, or that GCC does some kind of stack "filling" to
> > trigger the guard page which OCaml does not do.
> 
> This is easy to trigger, right? Can you catch it in gdb and 't a a bt'

I won't bore you with the full stack trace, but the top and bottom
and some interesting registers are below.

It confirms a few things:

 - Stack is overflowing because of a highly recursive function (which
   does eventually bottom-out, if you give it a big enough stack).

 - Compiler is single threaded.

 - %r1 (at top) - %r1 (at bottom) is approximately 8 MB

 - Avg. size of each stack frame is ~ 168 bytes.

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
GNU gdb (GDB) Fedora 7.7.1-17.fc20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "ppc64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/rjones/local/bin/ocamlopt.opt...(no debugging 
symbols found)...done.
[?1034h(gdb) run
Starting program: /home/rjones/local/bin/ocamlopt.opt -c -g -w a -I 
camlp4/import -warn-error A-3 -I camlp4/config -I camlp4/boot -o 
camlp4/boot/camlp4boot.cmx camlp4/boot/camlp4boot.ml

Program received signal SIGSEGV, Segmentation fault.
0x100587cc in .camlCSEgen__compare_1011 ()
Missing separate debuginfos, use: debuginfo-install glibc-2.18-12.fc20.ppc64p7
(gdb) t a a bt

Thread 1 (process 48132):
#0  0x100587cc in .camlCSEgen__compare_1011 ()
#1  0x10007b48 in .caml_apply2 ()
#2  0x10263e44 in .camlMap__find_1091 ()
#3  0x10058d4c in .camlCSEgen__find_equation_1124 ()
#4  0x10057624 in .camlCSEgen__fun_1397 ()
#5  0x10007a84 in .caml_apply3 ()
#6  0x10057c5c in .camlCSEgen__fun_1397 ()
#7  0x10007a84 in .caml_apply3 ()
#8  0x10057c5c in .camlCSEgen__fun_1397 ()
#9  0x10007a84 in .caml_apply3 ()
#10 0x1005799c in .camlCSEgen__fun_1397 ()

[these two stack frames are repeated over and over]

#49873 0x10007a85 in .caml_apply3 ()
#49874 0x10057d51 in .camlCSEgen__fun_1397 ()
#49875 0x10007a85 in .caml_apply3 ()
#49876 0x10057d51 in .camlCSEgen__fun_1397 ()
#49877 0x10007a85 in .caml_apply3 ()
#49878 0x10057315 in .camlCSEgen__fun_1406 ()
#49879 0x10006a41 in .caml_send1 ()
#49880 0x10059ea9 in .camlCSE__fundecl_1029 ()
#49881 0x1007c59d in .camlAsmgen__compile_fundecl_1050 ()
#49882 0x1007c895 in .camlAsmgen__compile_phrase_1053 ()
#49883 0x1007bbe9 in .camlAsmgen__fun_1285 ()
#49884 0x10258a01 in .camlList__iter_1061 ()
#49885 0x1007bc2d in .camlAsmgen__fun_1290 ()
#49886 0x1007cc49 in .camlAsmgen__compile_implementation_1063 ()
#49887 0x10082da9 in .camlOptcompile__fun_1274 ()
#49888 0x10083525 in .camlOptcompile__comp_1048 ()
#49889 0x10083de1 in .camlOptcompile__implementation_1040 ()
#49890 0x10007cd9 in .camlOptmain__process_implementation_file_1011 ()
#49891 0x10008445 in .camlOptmain__process_file_1016 ()
#49892 0x100084c5 in .camlOptmain__anonymous_1022 ()
#49893 0x10283ec5 in .camlArg__parse_argv_dynamic_1078 ()
#49894 0x10284161 in .camlArg__parse_1140 ()
#49895 0x100092bd in .camlOptmain__main_1474 ()
#49896 0x1000a785 in .camlOptmain__entry ()
#49897 0x10003439 in caml_startup.code_begin ()
#49898 0x102b633d in .caml_start_program ()
#49899 0x000

Re: Default stack size

[Orion Poplawski]

On 03/24/2015 06:19 AM, 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.
> 
> One way to "fix" this would be to modify every single ocaml-* spec
> file to add:
> 
> %ifarch %{power64}
> ulimit -s 65536
> %endif

FWIW - coincidentally I just ran into a similar issue building gdl on EPEL6
for x86_64.  I couldn't reproduce it locally because I bump up the default
stack limit a bit on my machines.  It does appear that the default may be a
bit too constrained.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Schedule for Thursday's FPC Meeting (2015-03-26 16:00 UTC) Followup:1 New:5

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2015-03-26 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2015-03-26 09:00 Thu US/Pacific PDT
2015-03-26 12:00 Thu US/Eastern EDT
2015-03-26 16:00 Thu UTC <-
2015-03-26 16:00 Thu Europe/London <-
2015-03-26 17:00 Thu Europe/Paris   CET
2015-03-26 17:00 Thu Europe/Berlin  CET
2015-03-26 21:30 Thu Asia/Calcutta  IST
--new day--
2015-03-27 00:00 Fri Asia/Singapore SGT
2015-03-27 00:00 Fri Asia/Hong_Kong HKT
2015-03-27 01:00 Fri Asia/Tokyo JST
2015-03-27 02:00 Fri Australia/Brisbane EST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/13

= Followups =

#topic #303 Consider reverting decision to ban %{?_isa} in BuildRequires
.fpc 303
https://fedorahosted.org/fpc/ticket/303

= New business =

#topic #513 Use python -Es in shbang
.fpc 513
https://fedorahosted.org/fpc/ticket/513

#topic #515 Bundling determination and exception request
.fpc 515
https://fedorahosted.org/fpc/ticket/515

#topic #516 Bundling exception for Thymeleaf
.fpc 516
https://fedorahosted.org/fpc/ticket/516

#topic #518 Confusion about '+' in a package name 
.fpc 518
https://fedorahosted.org/fpc/ticket/518

#topic #519 Old filters in guidelines example
.fpc 519
https://fedorahosted.org/fpc/ticket/519

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://fedorahosted.org/fpc/report/13

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

5tFTW: Fedora conferences this summer, writing release notes, brainstorming a better onramp, and a GSOC reminder (2015-03-25)

[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-brainstorm-session/


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 Millermat...@mattdm.org 
Fedora Project Leader  mat...@fedoraproject.org   
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ppc] Default stack size on ppc64

[David Woodhouse]

On Wed, 2015-03-25 at 19:45 +, Richard W.M. Jones wrote:
> On Wed, Mar 25, 2015 at 06:30:25PM +, David Woodhouse wrote:
> > 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...
> 
> Just so I'm clear, is the stack supposed to grow down automatically
> (ie. does the stack automatically use MAP_GROWSDOWN), or is OCaml
> supposed to do something when the stack hits the guard page?
> 
> I guess it's also possible that an OCaml stack frame is so big that it
> skips the guard page, or that GCC does some kind of stack "filling" to
> trigger the guard page which OCaml does not do.

This is easy to trigger, right? Can you catch it in gdb and 't a a bt'


-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ppc] Default stack size on ppc64

[Richard W.M. Jones]

On Wed, Mar 25, 2015 at 06:30:25PM +, David Woodhouse wrote:
> 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...

Just so I'm clear, is the stack supposed to grow down automatically
(ie. does the stack automatically use MAP_GROWSDOWN), or is OCaml
supposed to do something when the stack hits the guard page?

I guess it's also possible that an OCaml stack frame is so big that it
skips the guard page, or that GCC does some kind of stack "filling" to
trigger the guard page which OCaml does not do.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Pushing the extra AppData files into Rawhide

[Richard Hughes]

In the effort to make the AppStream generation simpler I'm going to
deprecate the fedora-appstream repo[1]. This was always designed to be
a stop-gap until upstreams had done new tarball releases and to
"rescue" applications that we care a lot about, and we're now at a
point where over 50% of upstream software ships AppData and the
general consensus upstream and downstream is that AppData is a good
thing. We've now even put the requirement for AppData in our packaging
guidelines.

I would ask the package maintainer (or a proven packager) to move the
AppData files in the srpm itself. I'm happy to help for the
lost-maintainer case but there are just too many for me to do myself.
All the .appdata.xml files have been sent upstream and if the
downstream package maintainer isn't happy shipping it them we should
just drop the file. The fedora-appstream repo was never meant to be a
long term solution and is slowly turning into a graveyard.

The preferred way of doing this is to add a new "Source" in the .spec,
to upload the file using fedpkg new-sources and then to install the
file using something like "install -Dm 0644 -p %{SOURCE2}
%{buildroot}%{_datadir}/appdata/foo.appdata.xml" but you can also
install it using the EOF trick too.

If the AppData file already exists upstream, please let me know. I
should have already removed all distro-overrides where an upstream
file exists, but there are a few apps that ship a file in the tarball
without installing it.

The spreadsheet is here:
https://docs.google.com/spreadsheets/d/1V6Oa9yP4oHFvbwyd0aNjEL92LUmKclLQJGsAbkRMHE8/edit?usp=sharing
-- I can't promise cookies, but I'll really appreciate it and it means
the applications won't disappear from Fedora 23. Yell if you have any
questions.

Thanks,

Richard

[1] https://github.com/hughsie/fedora-appstream/

Affected desktop files:
abiword
Add64
aeskulap
alexandria
amoebax
amulegui
arcstat-ui
ardour2
armacycles-ad
ascend4
astromenace
asylum
atanks
ballz
barrage
billiards
biloba
blender
blobwars
BlockOutII
bpython
bssh
btanks
bvnc
bzflag
calibrate_lens_gui
cave9
cbrpager
ccgo
celestia
chinese-calendar
chocolate-doom
chromium
CMake
colossus
Coot
CriticalMass
crossfire-client
CRRCsim
CUBE
darkplaces-quake
dia
diffuse
dispcalGUI-3DLUT-maker
dispcalGUI-curve-viewer
dispcalGUI-profile-info
dispcalGUI-synthprofile
dispcalGUI-testchart-editor
dispcalGUI-VRML-to-X3D-converter
doom
dreampie
dsi
echomixer
edb
edfviewer
edgar
elementsinfo
emacsclient
envy24control
escape
eyesight
fbg2
fbzx
file-roller
fillets
findthatword
firefox
flare
flarq
flaw
fldigi-doc
FlightGear
font-manager
fontmatrix
fonts-tweak-tool
freeciv
freeciv-modpack
freediams
freedoom
freemedforms
frozen-bubble
funguloids
gambas
GammaRay
garden
gda-browser-5.0
geany
geeqie
giggle
git-dag
glade-3
glc_player
glob2
globaltime
gnome-disks
gnome-ekiga
gnome-nettool
gnome-phone-manager
gnome-search-tool
gnome-subtitles
gnome-system-log
GNUSim8085
gobby
gogui
goldendict
gphpedit
gpick
gpodder
groovy
gtg
gtranslator
guitone
gvim
gvrng
gweled
gwget
hamster-time-tracker-overview
hatari
haxima
hdspconf
hdspmixer
heimdall
hexglass
hgview
hotot
hotot-qt
iep
inkscape
jaxodraw
k3d
kajongg
kalgebramobile
kapman
kbibtex
key-mon
KGoldrunner
kollision
krusader_root-mode
ksudoku
kubrick
ladi-system-tray
lbrickbuster2
LibreAtlas
librecad
lincity-ng
lingot
lordsawar
luminance-hdr
luxrender
lxmusic
manaplus
mandelbulber
mca2edf
megaglest
memaker
methane
MiniCopier
mj
monodevelop
mousepad
mozilla-thunderbird
mtpaint
musique
mypaint
naev
nemiver
netpanzer
neverball
neverputt
nomacs
octave
office-runner
oggconvert
openalchemist
openarena
openlierox
openmsx
openshot
openttd
opticalraytracer
orca
org.gnome.Screenshot
Panini
pdfmod
pdfshuffler
peakidentifier
phatch
phatch-inspector
picmi
pingus
pinta
pioneers
planner
plee-the-bear
plotdrop
postr
PTBatcherGUI
pychess
pymcabatch
pymcapostbatch
pymcaroitool
qcomicbook
qt4-linguist
quasselclient
rafkill
rawtherapee
redeclipse
revelation
rocksndiamonds
scinotes
scorched3d
screengrab
screenie-composer
scribus
setroubleshoot
shutter
sir
skanlite
smb4k
sound-juicer
speed-dreams
springlobby
stoken-gui-small
sublime_text
subtitleeditor
sudoku-savant
supertuxkart
tagtool
teeworlds
tennix
Thunar
Thunar-bulk-rename
tintii
tomboy
torcs
transmission-gtk
tremulous
tuxguitar
tuxpaint
tuxtype2
uqm
uzbl
vdrift
viewnior
vlc
warmux
warzone2100
WebHTTrack-Websites
wesnoth
wings
wireshark
xchat
xcos
xmedcon
xmoto
xmove
xonotic
xpbsmon
xsane
xskat
xzgv
yelp
zaz
zynaddsubfx-jack
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ppc] Default stack size on ppc64

[Richard W.M. Jones]

On Wed, Mar 25, 2015 at 06:30:25PM +, David Woodhouse wrote:
> 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.

In summary: when you run ocamlopt to compile a sufficiently
complicated OCaml program, ocamlopt segfaults.  We found the cure is
to do 'ulimit -s 65536' before running ocamlopt.

> 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?

$ ulimit -s
8192

(For reference, all the limits are attached below).

That is from Fedora 20 ppc64 (not -le).  The server is a POWER 7
LPAR.  The page size is 64K.

I don't currently have access to a newer Fedora machine, but the same
segfault was reported in current Rawhide and it was cured in the same
way, so it seems unlikely that the default stack size is different there.

Rich.

$ ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 496059
max locked memory   (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 8192
cpu time   (seconds, -t) unlimited
max user processes  (-u) 4096
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Summary/Minutes from today's FESCo Meeting (2015-03-25)

[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-25-18.00.log.html
.



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/Harden_all_packages_with_position-independent_code
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  #startmeeting FESCO (2015-03-25)
18:00:02  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  Useful Commands: #action #agreed #halp #info #idea
#link #topic.
18:00:02  #meetingname fesco
18:00:02  The meeting name has been set to 'fesco'
18:00:02  #chair ajax dgilmore jwb mitr nirik paragan rishi
thozza sgallagh
18:00:02  #topic init process
18:00:02  Current chairs: ajax dgilmore jwb mitr nirik paragan
rishi sgallagh thozza
18:00:16  morning.
18:00:16  hi
18:00:20  Hi all
18:00:22  hi
18:00:26  Hello
18:00:30  I have to run in an hour
18:00:35  hi
18:00:58  we are missing sgallagh_afk  and rishi
18:01:26  Okay let's start
18:01:37  #topic #1312 F22 System Wide Change: Replace Yum
With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
18:01:37  .fesco 1312
18:01:40  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  dnf developer has given the proposal in
https://fedorahosted.org/fesco/ticket/1312#comment:29
18:02:30  +1
18:02:32 * ajax waves
18:02:50  anyone have any issues with his proposal?
18:03:03  paragan: I'm +1 on it.
18:03:11  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  looks fine to me, +1
18:03:33  right this should have happened before alpha
18:04:06  i've had fewer issues with dnf in f22 than i've had
with yum, tbh
18:04:42  actually yum (as in the tool) should go away the
libary / apis should be there to give users some porting time
18:04:48  well, dnf has it's quirks, but it's the future! and
we are just more used to yum's really...
18:04:53  i don't think the timing should block the proposal,
given how long its taken to get even to this point.
18:05:00  I don't see a reason for a "yum-decprecated"
command but well ...
18:05:02  (talk talk talk)
18:05:13  right, unless it doesn't land before beta freeze.
18:06:07  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  +1
18:06:16  (again)
18:06:18  sure, +1
18:06:20  +1 again
18:06:21  I am +1
18:06:50  (And please make sure this is done by beta freeze)
18:07:22  asap
18:07:29  I see +4 votes
18:07:38  any more votes?
18:08:03  +1
18:08:23  #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  #topic #1384 F23 System Wide 

Re: [ppc] Default stack size on ppc64

[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


smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: unzip - support of segmented archives - look for volunteers for testings

[Petr Stodulka]

I create repositories in copr for testing. So you can available my copr 
repositories by:

# dnf copr enable pstodulk/unzip

so you can use actual fedora-devel version with this feature. If some 
behaviour
is broken for unsegmented archives, it's important information too, so 
use it

and report it :-)

Thanks,
Petr


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




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ppc] Default stack size on ppc64

[Richard W.M. Jones]

On Wed, Mar 25, 2015 at 05:54:58PM +, Richard W.M. Jones wrote:
> 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?

Just after posting that I found the details:

https://gcc.gnu.org/wiki/SplitStacks

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ppc] Default stack size on ppc64

[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 +, 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: New notifications

[Pierre-Yves Chibon]

On Wed, Mar 25, 2015 at 08:35:22AM -0600, Jerry James wrote:
> Changing the subject to something more appropriate.
> 
> On Tue, Mar 24, 2015 at 9:35 AM, Pierre-Yves Chibon  
> 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.

This is odd, would you mind dropping by on #fedora-apps to help us diagnose the
problem?

> 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

This link is being/going to be removed very soon, it is indeed pretty useless as
no-one can access the account there but the FMN admins, so we are working on
this :)


Thanks for your reports,
Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New notifications

[Jerry James]

Changing the subject to something more appropriate.

On Tue, Mar 24, 2015 at 9:35 AM, Pierre-Yves Chibon  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/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Lazarus broken for fedora 22

[Vít Ondruch]

Dne 25.3.2015 v 13:43 Richard Shaw napsal(a):
> On Wed, Mar 25, 2015 at 5:53 AM, Heiko Adams  > wrote:
>
> -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.
>
>
> It took a while and a bit of effort on my part but I did get him to
> respond to my fpc BZ and now newer versions of fpc and lazarus have
> been built for Rawhide but now I'm trying to convince him to build for
> other releases, at least through f21 as I can't even build the new
> version of my package, cqrlog, without newer versions of both.
>
> Thanks,
> Richard 
>

Neither the recent version of lazarus (lazarus-1.4-0.1.RC2.fc23.x86_64)
works :/ But I think the cause is Gtk2.

Vít
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: "dnf search" as braindead as "yum search"

[Matthew Miller]

On Wed, Mar 25, 2015 at 10:03:39AM +0100, Miroslav Suchý wrote:
> To have nice full text search would mean to use full text search
> engine. And I suppose that this extra dependency in DNF would be not
> welcomed by many - including cloud SIG. However this can be easily
> done as plugin and put in dnf-plugins-extra.

Agreed -- not the best core functionality because of space, but I'd
definitely welcome full-text search on my desktop. Especially really
smart FTS where I could narrow down what fields are searched, like
"description:foo" or even "changelog:1048424".

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Lazarus broken for fedora 22

[Richard Shaw]

On Wed, Mar 25, 2015 at 5:53 AM, Heiko Adams  wrote:

> -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.


It took a while and a bit of effort on my part but I did get him to respond
to my fpc BZ and now newer versions of fpc and lazarus have been built for
Rawhide but now I'm trying to convince him to build for other releases, at
least through f21 as I can't even build the new version of my package,
cqrlog, without newer versions of both.

Thanks,
Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

unzip - support of segmented archives - look for volunteers for testings

[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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: New to the list, and... possible bug ?

[Petr Pisar]

On 2015-03-23, Hoggins!  wrote:
> Le 23/03/2015 16:56, Petr Pisar a =C3=A9crit :
> Actually, no. I've always had this "error", but it was working okay.
> Now, when I try to launch rollerd with : rollerd -rrfile
> /var/named/all.rollrec -directory /var/named/, either I get :
>
> undefined time at
> /usr/lib64/perl5/vendor_perl/Net/DNS/ZoneFile/Fast.pm line 203.
>  at /usr/lib64/perl5/vendor_perl/Net/DNS/ZoneFile/Fast.pm line 203.
> in new Net::DNS::RR( sigexpiration 20150420124526 typecovered SOA
> orgtt ... ) at /usr/lib64/perl5/vendor_perl/Net/DNS/ZoneFile/Fast.pm
> line 203.
[...]
> ***  The 1277 Net::DNS::RR::RRSIG object has no method 'first'
> ***  THIS IS A BUG IN THE CALLING SOFTWARE, which incorrectly assumes=
>
> ***  that the object would be of a particular type.  The type of an
> ***  object should be checked before calling any of its methods.
>  at /usr/lib64/perl5/vendor_perl/Net/DNS/RR.pm line 205.
> Net::DNS::RR::_new_hash called at
> /usr/lib64/perl5/vendor_perl/Net/DNS/RR.pm line 65
> eval {...} called at /usr/lib64/perl5/vendor_perl/Net/DNS/RR.pm
> line 66
> Net::DNS::RR::new("Net::DNS::RR", "labels", 2, "signame",
> "atelierpanel.com.", "keytag", 37568, "class", "IN", ...) called at
> /usr/lib64/perl5/vendor_perl/Net/DNS/ZoneFile/Fast.pm line 203
> Net::DNS::ZoneFile::Fast::parse("file",
> "/var/named/atelierpanel.com.hosts.signed") called at
> /usr/lib64/perl5/vendor_perl/Net/DNS/SEC/Tools/dnssectools.pm line 38=
> 2
>
It looks like dnssec-tools uses perl-Net-DNS incorrectly.

Please report it to the Bugzilla tool
.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Lazarus broken for fedora 22

[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-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Could we disable "AutoQA" until it can produce usable results?

[Kamil Paral]

> 
> Witness (a):
> https://admin.fedoraproject.org/updates/libguestfs-1.29.31-1.fc22
> 
> The log file in this case is 3452 lines long.
> 
> Witness (b):
> https://admin.fedoraproject.org/updates/ocaml-camlp4-4.02.0-0.9.git87c6a6b0.fc22
> 
> The log file in this case is 3452 lines long (not coincidentally - it
> is exactly the same file as above).
> 
> And in both cases the log files are a morass of randomness.

Sorry about this. Adam already noted how to search in those logs. Recently, we 
have implemented support for task artifacts, and split upgradepath results per 
build and per update, so you'll be able to see only the output relevant to you:
http://taskotron-dev.fedoraproject.org/artifacts/20150324/6a4b8934-d24c-11e4-8b08-52540073dd95/task_output/

We still don't have any way to present it to you easily (you need to know how 
to construct these arcane URLs), but we're working on it. And we still haven't 
implemented result splitting for depcheck yet.

In your exact case, this "inferior architecture" error message is a known 
irregularly occurring issue and it's a bug somewhere in depcheck or dependency 
solving stack, but we haven't been able to pinpoint it and fix it yet. Recently 
we have received some guidance from libsolv maintainer and we're trying to 
reproduce the problem with some debugging info. Unfortunately, it's quite 
difficult to reproduce.

Disabling the tests until they work flawlessly and we have a nice way of 
representing the results is on the table, if many maintainers think it's better 
than having at least some logs in some form. However, having this kind of 
feedback helps us to prioritize the tasks we work on.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: "dnf search" as braindead as "yum search"

[Miroslav Suchý]

On 03/24/2015 12:25 PM, Michael Schwendt wrote:
> Meanwhile I've already added a comment to a related RFE.
> I prefer filing bugs only if there is agreement/confirmation that it
> is considered a bug to fix eventually. It is entirely non-productive
> to open a ticket and have developers disagree or not respond to a
> ticket.
> 
> That's why I posted my thoughts here. When I search, I do it with
> repoquery and grep, because yum/dnf search isn't powerful enough and
> hence not helpful.

To have nice full text search would mean to use full text search engine. And I 
suppose that this extra dependency in DNF
would be not welcomed by many - including cloud SIG. However this can be easily 
done as plugin and put in dnf-plugins-extra.

-- 
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

arzub...@gmail.com

[Arzubek Murtazaev]

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct