Re: Save everybody some surprises in Fedora 22!

[Ales Kozumplik]

On 06/07/2014 10:55 PM, Garry T. Williams wrote:

On 6-6-14 14:46:23 Ales Kozumplik wrote:

We're
wondering: is there stuff people are still missing from DNF


The --advisory option.



Building updateinfo support is underway:

https://bugzilla.redhat.com/show_bug.cgi?id=850912

Ales
--
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: help needed to find a bug in zorba (or gcc 4.9)

[Petr Spacek]

On 10.6.2014 21:47, Martin Gieseking wrote:

Am 10.06.2014 20:44, schrieb Jerry James:

Here's the first problem pointed out by valgrind:
- class Store (src/store/naive/store.h) has a public member "zstring theEmptyNs"
- that object is set to a string that is also added to "StringPool
*theNamespacePool" inside Store::init() (src/store/naive/store.cpp)
- when the ZorbaImpl destructor runs on the singleton ZorbaImpl
object, it starts this call chain:
   o shutdownInternal(false)
   o StoreManager::shutdownStore(&GENV_STORE)
   o SimpleStore::shutdown(false)
   o Store::shutdown(false)
- Since theNamespacePool is non-NULL, we do this:
   theEmptyNs.~zstring();
   theXmlSchemaNs.~zstring();
   delete theNamespacePool;
   theNamespacePool = NULL;

We deleted theEmptyNs ... but left it sitting in theNamespacePool.  So
when theNamespacePool's destructor runs, it examines that string,
leading to the crash.  The same thing happens with theXmlSchemaNs.
The fix is to remove those strings from the StringPool instead of
explicitly deallocating them, and then let the Store destructor
actually delete the two strings, like so:



Jerry,

thank you for taking the time to look into the code and for tracking
down the first issue. However, it's the same one I already fixed with
patch 4 (zorba-namespace-pool.patch) present in the latest SRPM [1]
linked in my initial email. It has also been applied upstream already.



Unfortunately, it appears that that is not the only bug.  Valgrind
shows at least two more bugs, both also tied into SimpleStore and
Store somehow, but I'm out of time to look at them.


Yes, the remaining bugs are hard to isolate. They always occur in
conjunction with the zstring/rstring objects. I just can't find the
location where the memory gets corrupted so that the access to their
data fields fail...


Maybe you can try Valgrind & gdbserver:

http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-concept

I'm sorry if you already tried that :-)

Petr^2 Spacek


Off topic: the check for unicode/coll.h (ZORBA_HAVE_COLL_H) is failing
spuriously because CHECK_INCLUDE_FILES is used where
CHECK_INCLUDE_FILE_CXX should be used.  One fix is to do this in
%prep:
# Fix detection of unicode/coll.h
sed -i 's,\(CHECK_INCLUDE_FILE\)S\( ("unicode/coll.h"\),\1_CXX\2,'
CMakeLists.txt


Also thank you for this hint. I'm going to add the fix the bug and
report it upstream.

Martin

[1] http://mgieseki.fedorapeople.org/review/zorba-3.0.0-4.fc21.src.rpm


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

[Bug 1106265] perl-Twiggy: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1106265

Robin Lee  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Twiggy-0.1024-2.fc21
 Resolution|--- |RAWHIDE
Last Closed||2014-06-11 02:21:37



-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=n2dCn5YpO5&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Qt packages necessaries to develop for Android

[Orcan Ogetbil]

On Tue, Jun 10, 2014 at 7:49 PM, Kevin Kofler wrote:
> Eric Smith wrote:
>> IANAL, but multiple lawyers have told me that it is generally a bad idea
>> to go looking for patents, at least in the US.  If they're brought to your
>> attention, you should probably do whatever is necessary to avoid them, but
>> you shouldn't actively seek them out, even just to try to confirm that
>> you're not using anything patented.
>
> Hunting for patents is one thing (I wouldn't recommend it either), but
> looking for obviously patent-encumbered stuff (like MP3 codecs) is another.
>

That's not quite obvious anymore. Most MP3 patents have expired by
now. Whether any of the remaining handful of patents are violated by
an MP3 codec implementation needs some non-trivial consideration.

Orcan
-- 
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: Another bug on OpenSSL

[Rahul Sundaram]

Hi


On Tue, Jun 10, 2014 at 8:44 PM, Darin Perusich  wrote:

>
>
> Perhaps maintaining FIPS support as a patch set, much like how  "features"
> such as acl, slp, openssl, etc are added to rsync, would be a suitable
> approach. This would keep the extra crap like FIPS out of LibreSSL then if
> someone "needs" FIPS mode they could apply the patch set, open their
> wallets, and seek validation.
>

FIPS is already a patchset but certification is extremely expensive and
there should be a very compelling reason for commercial companies to
consider alternatives.

Rahul
-- 
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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Ralf Corsepius]

On 06/11/2014 02:08 AM, Matthew Miller wrote:

On Wed, Jun 11, 2014 at 02:00:13AM +0200, Kevin Kofler wrote:

That was overly critical of me and did nothing to actually further the
discussion. I apologise.

No need to apologize! It's just the truth: ARM is not ready to be a primary


Kevin, I disagree. A positive tone to discussion is important even when
speaking the truth.


Matthew, in this case, I concur with Kevin. The facts are obvious and 
because of this obviousness, the tone should not matter at all, IMO.


It's time to *openly* discuss and to *seriously question* the arm's 
position in Fedora, even though such a discussion and/or the outcome 
should show to be unpleasant and/or undesired to some people/entities 
and their plans/interests.


Ralf


--
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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Matthew Garrett]

On Wed, Jun 11, 2014 at 01:53:12AM +0200, Kevin Kofler wrote:
> Matthew Garrett wrote:
> > Eh. We're constrained by our own policies here, not by anything
> > fundamental - LLVM being broken on ARM ought to mean that our ARM
> > product is worse, not that everything else is dragged down to the same
> > level.
> 
> Didn't YOU vote for ARM as a primary architecture, and even actively lobby 
> for it? Now you get to pick the (poisoned) fruit…

Er. No? I think you're confusing me with someone else.

-- 
Matthew Garrett | mj...@srcf.ucam.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: Another bug on OpenSSL

[Darin Perusich]

On Tue, Jun 10, 2014 at 8:13 PM, Kevin Kofler 
wrote:

> Álvaro Castillo wrote:
> > However, OpenBSD was created a fork called LibreSSL try to solve this
> > issues. Should Fedora to move LibreSSL (http://www.libressl.org/)? Or
> > still use OpenSSL and wait what's bug could be found today, or
> > tomorrow, or few months to go similar Adobe Flash bugs?
>
> Since they deleted the FIPS mode among other things, I don't think it will
> show up in Fedora, ever. Red Hat needs FIPS compliance for RHEL.
>
>
Perhaps maintaining FIPS support as a patch set, much like how  "features"
such as acl, slp, openssl, etc are added to rsync, would be a suitable
approach. This would keep the extra crap like FIPS out of LibreSSL then if
someone "needs" FIPS mode they could apply the patch set, open their
wallets, and seek validation.

--
Later,
Darin
-- 
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: Another bug on OpenSSL

[Kevin Kofler]

Paul wrote:
> Perhaps moving from OpenSSL to NSS would be better if you are that worried
> about OpenSSL bugs

The problem is that nss-compat-ossl is not a drop-in replacement and as such 
basically useless. Upstream projects tend to support only OpenSSL.

Kevin Kofler

-- 
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: Another bug on OpenSSL

[Kevin Kofler]

Álvaro Castillo wrote:
> However, OpenBSD was created a fork called LibreSSL try to solve this
> issues. Should Fedora to move LibreSSL (http://www.libressl.org/)? Or
> still use OpenSSL and wait what's bug could be found today, or
> tomorrow, or few months to go similar Adobe Flash bugs?

Since they deleted the FIPS mode among other things, I don't think it will 
show up in Fedora, ever. Red Hat needs FIPS compliance for RHEL.

Kevin Kofler

-- 
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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Matthew Miller]

On Wed, Jun 11, 2014 at 02:00:13AM +0200, Kevin Kofler wrote:
> > That was overly critical of me and did nothing to actually further the
> > discussion. I apologise.
> No need to apologize! It's just the truth: ARM is not ready to be a primary 

Kevin, I disagree. A positive tone to discussion is important even when
speaking the truth.


-- 
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: Save everybody some surprises in Fedora 22!

[Kevin Kofler]

Garry T. Williams wrote:
> The --advisory option.

That's indeed very important. The most convenient method to test individual 
updates from testing, no matter how many packages are in the update group 
nor how many subpackages they have. (Despite the naming, it is not limited 
to security updates, by the way.)

Another one that also doesn't show up in the list is --downloadonly. It is 
needed to do safe distribution upgrades with minimal downtime (first 
download everything, then run the upgrade from cache in the text-only
multi-user.target).

Kevin Kofler

-- 
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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Kevin Kofler]

Matthew Garrett wrote:

> On Tue, Jun 10, 2014 at 07:11:53PM +0100, Matthew Garrett wrote:
>> 
>> If the Fedora/ARM community don't care about feature parity with x86,
>> then we should just drop them back to secondary status.

+1, and:

> That was overly critical of me and did nothing to actually further the
> discussion. I apologise.

No need to apologize! It's just the truth: ARM is not ready to be a primary 
architecture, and might not even be for years to come. (Just look at build 
times, which are still 2+ times slower than x86, entirely unacceptable! All 
my builds are always blocking on ARM slowness now.) It should never have 
been made primary in the first place, and this ought to be fixed ASAP.

Kevin Kofler

-- 
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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Kevin Kofler]

Matthew Garrett wrote:
> Eh. We're constrained by our own policies here, not by anything
> fundamental - LLVM being broken on ARM ought to mean that our ARM
> product is worse, not that everything else is dragged down to the same
> level.

Didn't YOU vote for ARM as a primary architecture, and even actively lobby 
for it? Now you get to pick the (poisoned) fruit…

This nonsense is exactly what "primary architecture" means.

Kevin Kofler

-- 
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: Qt packages necessaries to develop for Android

[Kevin Kofler]

Eric Smith wrote:
> IANAL, but multiple lawyers have told me that it is generally a bad idea
> to go looking for patents, at least in the US.  If they're brought to your
> attention, you should probably do whatever is necessary to avoid them, but
> you shouldn't actively seek them out, even just to try to confirm that
> you're not using anything patented.

Hunting for patents is one thing (I wouldn't recommend it either), but 
looking for obviously patent-encumbered stuff (like MP3 codecs) is another.

Kevin Kofler

-- 
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: Qt packages necessaries to develop for Android

[Kevin Kofler]

drago01 wrote:
> We have been shipping patented code in freetype for a while (until it
> expired) we just disabled it at build time.

But this has never been compliant with Fedora Legal policies.

  Kevin Kofler

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

An update on System Tray, Plasma Next ("KDE 5") and GTK+

[Kevin Kofler]

Hi,

Quoting from Marco Martin's blog post:
http://notmart.org/blog/2014/06/systemtray-plasma-next-and-gtk/
(Annotations from me are enclosed in parentheses.)

> You may have heard that KDE Plasma Next won’t support anymore the old
> X11,Xembed-based systemtray icons.

(KDE Plasma Next is the next major version of the KDE workspace(s), to
replace the current KDE Plasma 4 workspace(s). In particular, the new
version is scheduled to replace KDE Plasma Desktop 4 in Fedora 22.)

> (More information here
> [http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/])

(I already posted a message to this mailing list back then.)

> Years ago, we developed a nicer, model/view based alternative in which is
> the shell that actually draws the systemtray icon, allowing better
> integration with the workspace, it’s a specification that is now shared
> between KDE and Ubuntu Unity.
> All KDE applications use it already, Qt4/Qt5-only application will use it
> depending on a small patch (and soon Qt5 will do out of the box)
>
> But also GTK has some options: until today I was aware only about the
> Ubuntu’s appindicator library [https://launchpad.net/libappindicator], but
> I have just been contacted by the author of another neat library, that can
> be found here on GitHub [https://github.com/jjk-jacky/statusnotifier].
> It’s a very small, few dependencies GObject-based library that allows a
> GTK3 application to export and control a statusnotifier-based systemtray
> icon. I just tested it on KDE4 and Plasma Next and seems to work quite
> well.
> So if you have a GTK application that is using a systemtray icon, and you
> would like the icon to be integrated in the next version of Plasma as
> well, now you have an option more (and of course, the author will be happy
> of any patch/bugreport/bugfix).

(Short version: If you maintain a GTK+ application that uses system tray
icons, please work with upstream on getting it ported to either
https://launchpad.net/libappindicator or
https://github.com/jjk-jacky/statusnotifier by Fedora 22 at the latest, or
enable existing upstream support ASAP.)

Kevin Kofler

-- 
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: Fedora 21 Mass rebuild update

[Peter Robinson]

On Tue, Jun 10, 2014 at 11:49 PM, Sérgio Basto  wrote:
> On Ter, 2014-06-10 at 17:40 -0500, Dennis Gilmore wrote:
>> On Tue, 10 Jun 2014 23:24:41 +0100
>> Sérgio Basto  wrote:
>>
>> > Hi,
>> >
>> > On Sáb, 2014-06-07 at 08:51 -0500, Dennis Gilmore wrote:
>> > > [2] http://ausil.fedorapeople.org/f21-need-rebuild.html
>> >
>> > Mass rebuild stopped ? or script stopped ?
>>
>> Not sure what exactly you are trying to ask,
>
> Since yesterday "need rebuild script" says that have 1052 packages that
> need rebuilding, now says 1050 other script says 907 failed builds.
>
> the automatic mass rebuild has finished or not ?

It's finished, the packages in that list are broken and failed during
the mass rebuild and need manual intervention to be fixed.

Peter
-- 
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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

[Peter Robinson]

>> If you're going on just the bug tracker possibly but there's a lot of
>> stuff we fix and enhance that doesn't even make the that tracker, the
>> Ada stuff I mentioned earlier is but one example. Rightly or wrongly
>> it's not the canonical source of information. For example if I
>> discover an exclude arch I'll generally just go and fix it rather than
>> spending the time to open a bug, fix it myself and then close it
>> myself. Just go and read the rawhide reports. If that's what you want
>> us to do to give a warm fuzzy feeling of progress I don't see it
>> as a time effective agile way of necessarily dealing with it. Feel
>> free to suggest alternatives :-)
>
> Ok, I was entirely unaware of that, and it does change things. Thanks
> for letting me know. I'll look into whether it's practical to generate a
> list of all the existing ExcludeArch packages and automatically check
> whether they have tracker bugs filed - does that seem helpful? It
> *would* be good to have meaningful metrics on this, but I don't want
> there to be excessive process overhead.

I agree metrics would be useful for all involved.

>> > Where there's reliance on specific hardware functionality that's absent
>> > then yes, absolutely, there's no benefit in building the packages.
>> > Figuring out how to communicate that to users isn't an entirely solved
>> > problem, but with luck nobody's actually buying ARM hardware with
>> > unrealistic expectations of its functionality.
>> >
>> > But I can't find any examples of those in the tracker. They all seem to
>> > be cases where packages are either missing dependencies, take too long
>> > to build or are just missing support. They're code. We can fix them.
>>
>> Are you offering to do so? For example some time ago I approached one
>> of the root maintainers (comes out of CERN I believe) and they said
>> they didn't see the point nor have the time to maintain anything other
>> than x86 at this time. Should we fork it and support it just to say
>> we're "feature complete with x86" just because it's code? Well maybe,
>> but I'm not sure in that case it would add value to the distro for the
>> expenditure of time and we've had exactly zero enquires about it (and
>> it's 3 dependencies in the tracker). In the case of Hadoop there might
>> possibly be value (and in later releases the issues might even have
>> been fixed) but again we've had no queries and so we've focused on
>> things people want. In the case of Ada we had some requests for
>> support since F-20 was released so we've added that for F-21.
>
> Yeah, I think where it's practical for us to maintain feature
> compatibility we should do so even if upstream disagree. We make
> modifications to upstream code all the time in order to meet Fedora
> policy.

I agree it's worth the effort where there's the demand for it, we
already do this for some packages on ARM where upstream don't support
it because people want to use it. I don't really see the point in
expending limited resources where there's no demand.

> As for who should be doing that work - well, yeah. That's kind of my
> point. Responsibility for this kind of thing is really something we
> should have figured out prior to promotion, and I'm sorry that I didn't
> think about it in a more timely manner. I'm looking for answers here,
> not insisting that anyone take on more work.
>
>> > I'm genuinely sorry if I gave the impression of bullying here. I want to
>> > feel comfortable pointing at the ARM port as an equal to the x86_64 one.
>> > I don't feel entirely comfortable doing so at the moment, and the
>> > current process doesn't seem to be getting us to the point where I would
>> > be.
>>
>> Well you need to engage with us better. Every time you make an
>> appearance it appears to us all it's just to bully us. People
>> genuinely shudder when your nick appears on on the channel and I've
>> had 3 people thank me for replying so they don't have to.
>
> That's unfortunate. I'm sorry. I'll try to ensure that I'm interacting
> in a more productive way.
>
>> So moving on from that why don't you feel comfortable pointing to
>> the ARM port? I'm aware we're still not perfect but it was always
>> going to be a road to improvement.
>
> Basically that you're still not perfect, to the extent that anything in
> Fedora is. I'd have been significantly happier if more time had been
> spent on, for instance, Anaconda before ARM was promoted. But
> realistically there's obviously a tension between perfectionism and
> maintaining enthusiasm - especially with the longer F21 cycle, I suspect
> the right decisions were made at the time.
>
>> We're supporting massively more hardware now than we were at F-20
>> release time and the types of HW are getting better with the likes of
>> the Tegra K1 supporting full desktop equivalent graphics and we might
>> even have the support for that upstream in time for F-21 release, the
>> open graphics drivers are improving that they might be usable in

Re: Fedora 21 Mass rebuild update

[Sérgio Basto]

On Ter, 2014-06-10 at 17:40 -0500, Dennis Gilmore wrote: 
> On Tue, 10 Jun 2014 23:24:41 +0100
> Sérgio Basto  wrote:
> 
> > Hi, 
> > 
> > On Sáb, 2014-06-07 at 08:51 -0500, Dennis Gilmore wrote:
> > > [2] http://ausil.fedorapeople.org/f21-need-rebuild.html
> > 
> > Mass rebuild stopped ? or script stopped ? 
> 
> Not sure what exactly you are trying to ask, 

Since yesterday "need rebuild script" says that have 1052 packages that
need rebuilding, now says 1050 other script says 907 failed builds. 

the automatic mass rebuild has finished or not ? 


> but that is the list of
> packages that needs to be built. it includes packages that have been
> submitted but failed to build.
> 
> Dennis

-- 
Sérgio M. B.

-- 
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: Fedora 21 Mass rebuild update

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 10 Jun 2014 23:24:41 +0100
Sérgio Basto  wrote:

> Hi, 
> 
> On Sáb, 2014-06-07 at 08:51 -0500, Dennis Gilmore wrote:
> > [2] http://ausil.fedorapeople.org/f21-need-rebuild.html
> 
> Mass rebuild stopped ? or script stopped ? 

Not sure what exactly you are trying to ask, but that is the list of
packages that needs to be built. it includes packages that have been
submitted but failed to build.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTl4leAAoJEH7ltONmPFDRGG4QAJS/mQjwnqWRcaWQ1AVyV8v+
wuLbxbpRpPwBBJ6CNoKvrTFr+/UBEaq5JqfU6XEya2L7JCJnx4/Tnbvhw9+U5C+n
1ZKe8fcf9uOwCqgZPxRlAamAen0utNM6tYbRPKosjsfrPQshQPcAtLLP6z1bzOM1
6moc1wcB0LhTk5c08HZ/4qKkTlAPK7HprAWECNYRAaNOnZ5k/WkZcZ9g4qlGv1jH
PqQM0RW07lgCKM0nvokR+FZfxReLXP9xCeUxfuDJntrFlwty2+myMA3OE7nPpGbr
A/ioc3cxLJTJhzZkVyWRbHhC16dJRDLAepzARVTYxtha4AQ+4bndLGdgqxCUnG9y
IaLEP5EUlJCt6PZXp1xJEa4+pbPYyuUimRM2zJhWqxRP9FQpS1htc/kjYhf2sL/4
eagoDRDJJa4R0q9sqT7CZZy7PdCzEtx271zS3KHMKJLeIMfpgmK6Ob5qsXBAH8Sp
gMHthkT6l8cEb+RNHLtVxYqxSWDAVrbjNUN+QLWF8clho8msR9btQOcQkC8+/Vgb
58QXC2IzTh52uu+alwIKK6pvi0+TsuXfti9gEm3/h91ZZwZ8C6kluX+lhEN2cYMm
wfY1ti2aZi4HjyYjfi8Qct0g460bEpMh/J4mPWCRDhLI8lTmRiodHYyhwPGPXcJq
qub4bHphKmbZ+HZVPU2A
=hwqJ
-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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

[Peter Robinson]

On Tue, Jun 10, 2014 at 11:07 PM, drago01  wrote:
> On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson  wrote:
>> [...]
>> So moving on from that why don't you feel comfortable pointing to
>> the ARM port?
>
> The question wasn't really directed at me but adding my 2 cents ...
> basically on x86(_64) hardware I can point people at fedora and most
> of the time it will work.
> As for ARM if you get a random arm hardware chances are that it is
> simply not supported or needs some manual hacks to get used.
>
> That's not really a fedora specific problem but it makes ARM more of a
> "gimmick" to me  ...  until hardware vendors catch up.

And the firmware side of things too, this is going to much better for
a lot of devices in F-21 where the process will be much more straight
forward and more robust. The amount of devices that should be
supportable will be expanded by an order of magnitude too, as it
stands at the moment the devices have over quadrupled since F-20 GA.

In some cases this has been a case of chicken and egg and we've seen
active engagement from a number of angles here since F-20 has gone GA
and we'll see these improvements in new HW, in some cases already HW
that is available on the market. For me at least given the
fragmentation of the ARM market up until recently it's not
particularly surprising and we've been some what on the bleeding edge
of that. We were the first distro to adopt the multiplatform kernel
and keep with the upstream first that has served the project well but
this has often cost in HW support but saved us in that we've not had
to juggle 100s of crappy vendor patches in dozens of kernels in a
means that's not really scalable without a paid kernel team to support
it.

I'm hoping that we're finally on the downhill, and the level of
devices that are being added easily and "just work", seems to back up
that hope and while there's always a long way to go the experience
will be better in the F-21 timeframe. Again would love feedback and
constructive suggestions to how we can improve this.

Peter
-- 
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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

[Matthew Garrett]

On Tue, Jun 10, 2014 at 10:52:19PM +0100, Peter Robinson wrote:
> On Tue, Jun 10, 2014 at 10:20 PM, Matthew Garrett  wrote:
> > In the past 6 months, 6 bugs added, 2 bugs closed -
> > https://bugzilla.redhat.com/show_activity.cgi?id=485251 .
> 
> If you're going on just the bug tracker possibly but there's a lot of
> stuff we fix and enhance that doesn't even make the that tracker, the
> Ada stuff I mentioned earlier is but one example. Rightly or wrongly
> it's not the canonical source of information. For example if I
> discover an exclude arch I'll generally just go and fix it rather than
> spending the time to open a bug, fix it myself and then close it
> myself. Just go and read the rawhide reports. If that's what you want
> us to do to give a warm fuzzy feeling of progress I don't see it
> as a time effective agile way of necessarily dealing with it. Feel
> free to suggest alternatives :-)

Ok, I was entirely unaware of that, and it does change things. Thanks 
for letting me know. I'll look into whether it's practical to generate a 
list of all the existing ExcludeArch packages and automatically check 
whether they have tracker bugs filed - does that seem helpful? It 
*would* be good to have meaningful metrics on this, but I don't want 
there to be excessive process overhead.

> > Where there's reliance on specific hardware functionality that's absent
> > then yes, absolutely, there's no benefit in building the packages.
> > Figuring out how to communicate that to users isn't an entirely solved
> > problem, but with luck nobody's actually buying ARM hardware with
> > unrealistic expectations of its functionality.
> >
> > But I can't find any examples of those in the tracker. They all seem to
> > be cases where packages are either missing dependencies, take too long
> > to build or are just missing support. They're code. We can fix them.
> 
> Are you offering to do so? For example some time ago I approached one
> of the root maintainers (comes out of CERN I believe) and they said
> they didn't see the point nor have the time to maintain anything other
> than x86 at this time. Should we fork it and support it just to say
> we're "feature complete with x86" just because it's code? Well maybe,
> but I'm not sure in that case it would add value to the distro for the
> expenditure of time and we've had exactly zero enquires about it (and
> it's 3 dependencies in the tracker). In the case of Hadoop there might
> possibly be value (and in later releases the issues might even have
> been fixed) but again we've had no queries and so we've focused on
> things people want. In the case of Ada we had some requests for
> support since F-20 was released so we've added that for F-21.

Yeah, I think where it's practical for us to maintain feature 
compatibility we should do so even if upstream disagree. We make 
modifications to upstream code all the time in order to meet Fedora 
policy.

As for who should be doing that work - well, yeah. That's kind of my 
point. Responsibility for this kind of thing is really something we 
should have figured out prior to promotion, and I'm sorry that I didn't 
think about it in a more timely manner. I'm looking for answers here, 
not insisting that anyone take on more work.

> > I'm genuinely sorry if I gave the impression of bullying here. I want to
> > feel comfortable pointing at the ARM port as an equal to the x86_64 one.
> > I don't feel entirely comfortable doing so at the moment, and the
> > current process doesn't seem to be getting us to the point where I would
> > be.
> 
> Well you need to engage with us better. Every time you make an
> appearance it appears to us all it's just to bully us. People
> genuinely shudder when your nick appears on on the channel and I've
> had 3 people thank me for replying so they don't have to.

That's unfortunate. I'm sorry. I'll try to ensure that I'm interacting 
in a more productive way.

> So moving on from that why don't you feel comfortable pointing to
> the ARM port? I'm aware we're still not perfect but it was always
> going to be a road to improvement.

Basically that you're still not perfect, to the extent that anything in 
Fedora is. I'd have been significantly happier if more time had been 
spent on, for instance, Anaconda before ARM was promoted. But 
realistically there's obviously a tension between perfectionism and 
maintaining enthusiasm - especially with the longer F21 cycle, I suspect 
the right decisions were made at the time.

> We're supporting massively more hardware now than we were at F-20
> release time and the types of HW are getting better with the likes of
> the Tegra K1 supporting full desktop equivalent graphics and we might
> even have the support for that upstream in time for F-21 release, the
> open graphics drivers are improving that they might be usable in that
> timeframe too. Those were problems that were well known when we went
> to primary and the path is basically what was agreed and mapped ou

Re: Fedora 21 Mass rebuild update

[Sérgio Basto]

Hi, 

On Sáb, 2014-06-07 at 08:51 -0500, Dennis Gilmore wrote:
> [2] http://ausil.fedorapeople.org/f21-need-rebuild.html

Mass rebuild stopped ? or script stopped ? 


-- 
Sérgio M. B.

-- 
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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

[drago01]

On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson  wrote:
> [...]
> So moving on from that why don't you feel comfortable pointing to
> the ARM port?

The question wasn't really directed at me but adding my 2 cents ...
basically on x86(_64) hardware I can point people at fedora and most
of the time it will work.
As for ARM if you get a random arm hardware chances are that it is
simply not supported or needs some manual hacks to get used.

That's not really a fedora specific problem but it makes ARM more of a
"gimmick" to me  ...  until hardware vendors catch up.
-- 
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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

[Peter Robinson]

On Tue, Jun 10, 2014 at 10:37 PM, Adam Goode  wrote:
> I seem to remember some kind of koji diff report that would come out
> periodically. Is there an automated run of this? I would love a
> dashboard or NxN matrix of diffs between all the arches. A timeseries
> would be perfect (to see the trends Matthew is referring to).
>
> Aha, found what I was thinking of:
> https://lists.fedoraproject.org/pipermail/arm/2013-February/005336.html

That was a diff between primarily and a secondary arch koji, not
actually a diff between x86 and ARM but rather an indication of how
far the secondary was behind primary in terms of pure package builds.
It was also generally quite inaccurate due to bugs in the script and
sometimes a single build failure of a core dependency could causes
bottle necks that could block builds due to dep chains and the fix to
that is always reactionary (get bug fixed, tested, pushed upstream,
generally manually build package to unblock bottle neck).

> Can this be rolled into automation in a more official way?

Not that I'm aware on a primary <-> primary diff with the current
tools. At the moment we basically ask rel-eng to use their mass check
out to to comparisons and that's generally on just Exclude/Exclusive
Arch and doesn't cover arch subsets of features of packages.

> Even something per-package like what Debian does is a start:
> https://packages.debian.org/wheezy/mlton-compiler
> vs.
> https://apps.fedoraproject.org/packages/mlton

The mention of PPC builds is presumably to to messages on the fedmsg
bus coming from the secondary arch PPC koji, the first in that list
covers all 3 mainline arches due to being a single koji instance.
Presumably koji/fedmsg could be enhanced to emit the arch builds
(arm/noarch/ix86/x86_64 too if it doesn't already and then pkgdb
display that info. I'll file a RFE, thanks for the suggestion.

Peter
-- 
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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

[Peter Robinson]

On Tue, Jun 10, 2014 at 10:20 PM, Matthew Garrett  wrote:
> On Tue, Jun 10, 2014 at 09:49:58PM +0100, Peter Robinson wrote:
>> > What's depressing is the trend, not the absolute count. I'd expected it
>> > to head rapidly towards zero after the first release, but instead it's
>> > still growing.
>>
>> Is it? Where's your proof? From the patches and dealings with it
>> personally that's not my understanding and if it is the case it's not
>> due to the ARM team but because packagers aren't following the
>> packaging process and in this case we actively fix them when we're
>> made aware of the incident.
>
> In the past 6 months, 6 bugs added, 2 bugs closed -
> https://bugzilla.redhat.com/show_activity.cgi?id=485251 .

If you're going on just the bug tracker possibly but there's a lot of
stuff we fix and enhance that doesn't even make the that tracker, the
Ada stuff I mentioned earlier is but one example. Rightly or wrongly
it's not the canonical source of information. For example if I
discover an exclude arch I'll generally just go and fix it rather than
spending the time to open a bug, fix it myself and then close it
myself. Just go and read the rawhide reports. If that's what you want
us to do to give a warm fuzzy feeling of progress I don't see it
as a time effective agile way of necessarily dealing with it. Feel
free to suggest alternatives :-)

>> > Anyone who has a usecase that relies on one of those packages will have
>> > an inconsistent experience if they attempt to reproduce it on ARM.
>> > That's harmful. It makes us look bad. It gives the appearance that we're
>> > willing to release a worse product simply in order to claim ARM support.
>>
>> And if they engage with us about that experience we do our best to
>> deal with them where possible. There's a few cases where I'm aware of
>> that we don't package because the HW is actively not supported on ARM
>> or similar style cases. In those cases I would argue that it's better
>> not to build the packages as arguably no experience is better
>> experience than a bad experience especially if there's potential of
>> issues that offer a worse experience, hardware breakage or data
>> corruption. The fact is that the x86 and ARM use cases don't match up
>> 100% and I don't see the point in trying to glue those together 100%
>> for the sake of a check box.
>
> Where there's reliance on specific hardware functionality that's absent
> then yes, absolutely, there's no benefit in building the packages.
> Figuring out how to communicate that to users isn't an entirely solved
> problem, but with luck nobody's actually buying ARM hardware with
> unrealistic expectations of its functionality.
>
> But I can't find any examples of those in the tracker. They all seem to
> be cases where packages are either missing dependencies, take too long
> to build or are just missing support. They're code. We can fix them.

Are you offering to do so? For example some time ago I approached one
of the root maintainers (comes out of CERN I believe) and they said
they didn't see the point nor have the time to maintain anything other
than x86 at this time. Should we fork it and support it just to say
we're "feature complete with x86" just because it's code? Well maybe,
but I'm not sure in that case it would add value to the distro for the
expenditure of time and we've had exactly zero enquires about it (and
it's 3 dependencies in the tracker). In the case of Hadoop there might
possibly be value (and in later releases the issues might even have
been fixed) but again we've had no queries and so we've focused on
things people want. In the case of Ada we had some requests for
support since F-20 was released so we've added that for F-21.

>> > I don't think the current state of the ARM port is good enough. That's
>> > not a reflection on the people involved. That's not a criticism of the
>> > amount of effort that's been made. I just want to know how we can get
>> > from where we currently are to where we want to be.
>>
>> Well why didn't you say that from the start rather than coming in and
>> bullying the people actively involved and make them feel like the
>> massive effort myself and many others have been putting in is useless
>> and a waste of time. Don't be a Magpie Board Member and fly in and
>> shit over everything and than fly awau with no concept of what's
>> happening below. Every time you've had any attempt at opinion that's
>> the way you've done it and all you do is get all our backs up and make
>> the problem worse rather than better.
>
> I'm genuinely sorry if I gave the impression of bullying here. I want to
> feel comfortable pointing at the ARM port as an equal to the x86_64 one.
> I don't feel entirely comfortable doing so at the moment, and the
> current process doesn't seem to be getting us to the point where I would
> be.

Well you need to engage with us better. Every time you make an
appearance it appears to us all it's just to bully us. People
genuinely shud

Re: Re: ORPHAN of mysql and python stuff

[Bob]

Pics? 

Sent from my iPhone
-- 
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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

[Matthew Garrett]

On Tue, Jun 10, 2014 at 09:49:58PM +0100, Peter Robinson wrote:
> > What's depressing is the trend, not the absolute count. I'd expected it
> > to head rapidly towards zero after the first release, but instead it's
> > still growing.
> 
> Is it? Where's your proof? From the patches and dealings with it
> personally that's not my understanding and if it is the case it's not
> due to the ARM team but because packagers aren't following the
> packaging process and in this case we actively fix them when we're
> made aware of the incident.

In the past 6 months, 6 bugs added, 2 bugs closed - 
https://bugzilla.redhat.com/show_activity.cgi?id=485251 .

> > Anyone who has a usecase that relies on one of those packages will have
> > an inconsistent experience if they attempt to reproduce it on ARM.
> > That's harmful. It makes us look bad. It gives the appearance that we're
> > willing to release a worse product simply in order to claim ARM support.
> 
> And if they engage with us about that experience we do our best to
> deal with them where possible. There's a few cases where I'm aware of
> that we don't package because the HW is actively not supported on ARM
> or similar style cases. In those cases I would argue that it's better
> not to build the packages as arguably no experience is better
> experience than a bad experience especially if there's potential of
> issues that offer a worse experience, hardware breakage or data
> corruption. The fact is that the x86 and ARM use cases don't match up
> 100% and I don't see the point in trying to glue those together 100%
> for the sake of a check box.

Where there's reliance on specific hardware functionality that's absent 
then yes, absolutely, there's no benefit in building the packages. 
Figuring out how to communicate that to users isn't an entirely solved 
problem, but with luck nobody's actually buying ARM hardware with 
unrealistic expectations of its functionality.

But I can't find any examples of those in the tracker. They all seem to 
be cases where packages are either missing dependencies, take too long 
to build or are just missing support. They're code. We can fix them.

> > I don't think the current state of the ARM port is good enough. That's
> > not a reflection on the people involved. That's not a criticism of the
> > amount of effort that's been made. I just want to know how we can get
> > from where we currently are to where we want to be.
> 
> Well why didn't you say that from the start rather than coming in and
> bullying the people actively involved and make them feel like the
> massive effort myself and many others have been putting in is useless
> and a waste of time. Don't be a Magpie Board Member and fly in and
> shit over everything and than fly awau with no concept of what's
> happening below. Every time you've had any attempt at opinion that's
> the way you've done it and all you do is get all our backs up and make
> the problem worse rather than better.

I'm genuinely sorry if I gave the impression of bullying here. I want to 
feel comfortable pointing at the ARM port as an equal to the x86_64 one. 
I don't feel entirely comfortable doing so at the moment, and the 
current process doesn't seem to be getting us to the point where I would 
be.

> >  Individual package
> > maintainers seem happy to just add an ExcludeArch, maybe file a bug
> > against upstream and then forget about the issue. Given a lack of direct
> > incentive for them to care about ARM, that's not terribly surprising.
> > What can we do about that? Is the only realistic answer to find the
> > resources to have a team to hunt down and fix portability issues that
> > are sufficiently far from the core that the existing ARM community can't
> > justify the time? And if so, is there any way we can make that happen?
> 
> I'm not sure I agree with your outline here, you've given no real
> concrete examples here. I agree there's no real incentive but there's
> over 15,000 source packages in Fedora and there's less than 100 (last
> time I looked, unfortunately there's no easy way off checking this
> without downloading the entire src.rpms or checking out all 15K git
> repos) or so excluded from ARM and the vast majority of those are due
> to HW support. There's some like D where upstream has yet to port the
> stack. I'm sure there's others I'm unaware of but it's not because of
> the ARM team but rather the packager following procedures or engaging
> us for assistance.

The quantity of the archive that's built and working on ARM so far is a 
testament to the amount of effort that the ARM community have put into 
this port. The question is how to finish that. All I'm saying here is 
that the current approach of filing bugs doesn't appear to be resulting 
in people actually fixing their packages. It's unreasonable to expect 
you to do all of it. So what do we do?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedorap

Re: making Ctrl-Alt-Bksp work

[Adam Williamson]

On Tue, 2014-05-13 at 09:56 +1000, Peter Hutterer wrote:

> > After reboot it succeeded, but I still wonder why CAD gets enabled
> > there at installation time for pt and de by not us. :-(
> 
> what's in your /etc/vconsole.conf? We've now reached a point where it's
> better to file a bug report though.

This could get messy.

For one thing I suspect i may be to do with it being the default layout;
perhaps this means anaconda never explicitly calls localed to write out
a config if you never change the layout from us. I'd have to dig into
anaconda to make sure.

The thing that makes it messy, though, is the vestigial bit of
system-config-keyboard / system-setup-keyboard that systemd/localed is
still lugging around, the Magic List of keyboard layouts called
kbd-model-map . It's in /usr/share/systemd/kbd-model-map on an installed
system, src/locale/kbd-model-map in a systemd git checkout.

A layout setting operation that gets run through that list is probably
going to get the terminate:ctrl_alt_bksp option set, because it's listed
in the 'xoptions' column of kbd-model-map for every layout that file
contains.

I no longer recall exactly when localed does and possibly does not use
kbd-model-map. I'd have to investigate a bit. And there may be other
wrinkles around the place. But that's at least one place to look. (An
obvious first test is to try an install with two similar non-default
keyboard layouts, one that's listed in kbd-model-map and one that isn't,
and see what happens).
-- 
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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

[Peter Robinson]

>> So at the moment there's around 15,000 source packages in Fedora
>> mainline and you're getting depressed over exactly 24 of them? I'm not
>> sure how 24 packages is providing a inconsistent experience. In some
>> cases the maintainer of the package hasn't bothered to close the bug
>> when support was added, in some cases ARM was added incorrectly. For
>> example just before mass rebuild we added Ada support which closed out
>> around 2 dozen other packages we didn't build prior.
>
> What's depressing is the trend, not the absolute count. I'd expected it
> to head rapidly towards zero after the first release, but instead it's
> still growing.

Is it? Where's your proof? From the patches and dealings with it
personally that's not my understanding and if it is the case it's not
due to the ARM team but because packagers aren't following the
packaging process and in this case we actively fix them when we're
made aware of the incident.

>> Ultimately I fail to see how missing 20 odd packages out of 15,000 odd
>> fails to "provide a consistent experience across primary
>> architectures" so if there's something more specific and constructive
>> you'd like to provide it would be useful or is this just a random rant
>> because your bored?
>
> Anyone who has a usecase that relies on one of those packages will have
> an inconsistent experience if they attempt to reproduce it on ARM.
> That's harmful. It makes us look bad. It gives the appearance that we're
> willing to release a worse product simply in order to claim ARM support.

And if they engage with us about that experience we do our best to
deal with them where possible. There's a few cases where I'm aware of
that we don't package because the HW is actively not supported on ARM
or similar style cases. In those cases I would argue that it's better
not to build the packages as arguably no experience is better
experience than a bad experience especially if there's potential of
issues that offer a worse experience, hardware breakage or data
corruption. The fact is that the x86 and ARM use cases don't match up
100% and I don't see the point in trying to glue those together 100%
for the sake of a check box.

>> Ultimately we've been working hard to provide as consistent
>> environment on ARM as possible and improving all the time and all you
>> seem to do is randomly come in Magpie style and shit on something
>> without any other visible involvement in the ARM process or community
>> or any context and pick on something of random like a bully. If you've
>> got constructive criticism feel free to engage properly to assist us
>> in improving and coming up to your exacting standards but this means
>> of bullying tactics isn't the way to do it.
>
> I don't think the current state of the ARM port is good enough. That's
> not a reflection on the people involved. That's not a criticism of the
> amount of effort that's been made. I just want to know how we can get
> from where we currently are to where we want to be.

Well why didn't you say that from the start rather than coming in and
bullying the people actively involved and make them feel like the
massive effort myself and many others have been putting in is useless
and a waste of time. Don't be a Magpie Board Member and fly in and
shit over everything and than fly awau with no concept of what's
happening below. Every time you've had any attempt at opinion that's
the way you've done it and all you do is get all our backs up and make
the problem worse rather than better.

>  Individual package
> maintainers seem happy to just add an ExcludeArch, maybe file a bug
> against upstream and then forget about the issue. Given a lack of direct
> incentive for them to care about ARM, that's not terribly surprising.
> What can we do about that? Is the only realistic answer to find the
> resources to have a team to hunt down and fix portability issues that
> are sufficiently far from the core that the existing ARM community can't
> justify the time? And if so, is there any way we can make that happen?

I'm not sure I agree with your outline here, you've given no real
concrete examples here. I agree there's no real incentive but there's
over 15,000 source packages in Fedora and there's less than 100 (last
time I looked, unfortunately there's no easy way off checking this
without downloading the entire src.rpms or checking out all 15K git
repos) or so excluded from ARM and the vast majority of those are due
to HW support. There's some like D where upstream has yet to port the
stack. I'm sure there's others I'm unaware of but it's not because of
the ARM team but rather the packager following procedures or engaging
us for assistance.

Peter
-- 
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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

[Matthew Garrett]

On Tue, Jun 10, 2014 at 09:12:35PM +0100, Peter Robinson wrote:

> So at the moment there's around 15,000 source packages in Fedora
> mainline and you're getting depressed over exactly 24 of them? I'm not
> sure how 24 packages is providing a inconsistent experience. In some
> cases the maintainer of the package hasn't bothered to close the bug
> when support was added, in some cases ARM was added incorrectly. For
> example just before mass rebuild we added Ada support which closed out
> around 2 dozen other packages we didn't build prior.

What's depressing is the trend, not the absolute count. I'd expected it 
to head rapidly towards zero after the first release, but instead it's 
still growing.

> Ultimately I fail to see how missing 20 odd packages out of 15,000 odd
> fails to "provide a consistent experience across primary
> architectures" so if there's something more specific and constructive
> you'd like to provide it would be useful or is this just a random rant
> because your bored?

Anyone who has a usecase that relies on one of those packages will have 
an inconsistent experience if they attempt to reproduce it on ARM. 
That's harmful. It makes us look bad. It gives the appearance that we're 
willing to release a worse product simply in order to claim ARM support.

> Ultimately we've been working hard to provide as consistent
> environment on ARM as possible and improving all the time and all you
> seem to do is randomly come in Magpie style and shit on something
> without any other visible involvement in the ARM process or community
> or any context and pick on something of random like a bully. If you've
> got constructive criticism feel free to engage properly to assist us
> in improving and coming up to your exacting standards but this means
> of bullying tactics isn't the way to do it.

I don't think the current state of the ARM port is good enough. That's 
not a reflection on the people involved. That's not a criticism of the 
amount of effort that's been made. I just want to know how we can get 
from where we currently are to where we want to be. Individual package 
maintainers seem happy to just add an ExcludeArch, maybe file a bug 
against upstream and then forget about the issue. Given a lack of direct 
incentive for them to care about ARM, that's not terribly surprising. 
What can we do about that? Is the only realistic answer to find the 
resources to have a team to hunt down and fix portability issues that 
are sufficiently far from the core that the existing ARM community can't 
justify the time? And if so, is there any way we can make that happen?

-- 
Matthew Garrett | mj...@srcf.ucam.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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

[Peter Robinson]

On Tue, Jun 10, 2014 at 7:28 PM, Matthew Garrett  wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=485251 is depressing. Nine
> bugs have been closed - of these, one is a review request that was
> dropped, two were incorrectly closed after an ExcludeArch was added and
> one was closed as a duplicate. Further, one bug was just unsubscribed
> from the tracker after tests were disabled. We've correctly fixed *five*
> packages that have been flagged as FTBFS on ARM. At this rate of fixing,
> and given the rate at which new bugs are added, ARM will never build the
> entire archive.
>
> Fedora is supposed to provide a consistent experience across primary
> architectures. Having a subset of our packages fail to build on ARM
> means that's not true, and the current state of affairs clearly violates
> point 8 of the architecture promotion requirements. How can we fix this?

So at the moment there's around 15,000 source packages in Fedora
mainline and you're getting depressed over exactly 24 of them? I'm not
sure how 24 packages is providing a inconsistent experience. In some
cases the maintainer of the package hasn't bothered to close the bug
when support was added, in some cases ARM was added incorrectly. For
example just before mass rebuild we added Ada support which closed out
around 2 dozen other packages we didn't build prior.

We actively fix bugs that come up but there's some there that just
currently don't make sense such as the ovirt-node package because
oVirt manager doesn't support ARM virtualisation (it's just added PPC,
it's first non x86 architecture, support as of the 3.4 release).

Some of these are because the upstream projects either refuse to
support ARM or it's using languages that aren't supported on ARM. In
the case of the mono packages in that it would be supported if the
mono stack was actively maintained in Fedora mainline in general.
There was a proposal for F-21 to update mono to the latest 3.x release
but while I've been watching it awaiting for it to land so we can test
it on ARM it's failed to materialise to date in mainline.

Ultimately I fail to see how missing 20 odd packages out of 15,000 odd
fails to "provide a consistent experience across primary
architectures" so if there's something more specific and constructive
you'd like to provide it would be useful or is this just a random rant
because your bored?

Ultimately we've been working hard to provide as consistent
environment on ARM as possible and improving all the time and all you
seem to do is randomly come in Magpie style and shit on something
without any other visible involvement in the ARM process or community
or any context and pick on something of random like a bully. If you've
got constructive criticism feel free to engage properly to assist us
in improving and coming up to your exacting standards but this means
of bullying tactics isn't the way to do it.

Peter
-- 
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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Bruno Wolff III]

On Tue, Jun 10, 2014 at 18:34:31 +0100,
 "Richard W.M. Jones"  wrote:

The relevant bit of the package guidelines is this:

 If a Fedora package does not successfully compile, build or work on an
 architecture, then those architectures should be listed in the spec in
 ExcludeArch. Each architecture listed in ExcludeArch needs to have a
 bug filed in bugzilla, describing the reason that the package does not
 compile/build/work on that architecture. The bug number should then be
 placed in a comment, next to the corresponding ExcludeArch line.


Do these bugs need to stay open? I have a couple of things that are 
exclude arch because they require kernel modules that aren't built 
for arm. I'm not expecting that to change ever in one case and probably 
not in the next few years (if ever) for the other case.

--
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: help needed to find a bug in zorba (or gcc 4.9)

[Martin Gieseking]

Am 10.06.2014 20:44, schrieb Jerry James:
> Here's the first problem pointed out by valgrind:
> - class Store (src/store/naive/store.h) has a public member "zstring 
> theEmptyNs"
> - that object is set to a string that is also added to "StringPool
> *theNamespacePool" inside Store::init() (src/store/naive/store.cpp)
> - when the ZorbaImpl destructor runs on the singleton ZorbaImpl
> object, it starts this call chain:
>   o shutdownInternal(false)
>   o StoreManager::shutdownStore(&GENV_STORE)
>   o SimpleStore::shutdown(false)
>   o Store::shutdown(false)
> - Since theNamespacePool is non-NULL, we do this:
>   theEmptyNs.~zstring();
>   theXmlSchemaNs.~zstring();
>   delete theNamespacePool;
>   theNamespacePool = NULL;
> 
> We deleted theEmptyNs ... but left it sitting in theNamespacePool.  So
> when theNamespacePool's destructor runs, it examines that string,
> leading to the crash.  The same thing happens with theXmlSchemaNs.
> The fix is to remove those strings from the StringPool instead of
> explicitly deallocating them, and then let the Store destructor
> actually delete the two strings, like so:


Jerry,

thank you for taking the time to look into the code and for tracking
down the first issue. However, it's the same one I already fixed with
patch 4 (zorba-namespace-pool.patch) present in the latest SRPM [1]
linked in my initial email. It has also been applied upstream already.


> Unfortunately, it appears that that is not the only bug.  Valgrind
> shows at least two more bugs, both also tied into SimpleStore and
> Store somehow, but I'm out of time to look at them.

Yes, the remaining bugs are hard to isolate. They always occur in
conjunction with the zstring/rstring objects. I just can't find the
location where the memory gets corrupted so that the access to their
data fields fail...


> Off topic: the check for unicode/coll.h (ZORBA_HAVE_COLL_H) is failing
> spuriously because CHECK_INCLUDE_FILES is used where
> CHECK_INCLUDE_FILE_CXX should be used.  One fix is to do this in
> %prep:
> # Fix detection of unicode/coll.h
> sed -i 's,\(CHECK_INCLUDE_FILE\)S\( ("unicode/coll.h"\),\1_CXX\2,'
> CMakeLists.txt

Also thank you for this hint. I'm going to add the fix the bug and
report it upstream.

Martin

[1] http://mgieseki.fedorapeople.org/review/zorba-3.0.0-4.fc21.src.rpm

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

libatasmart viability

[Przemek Klosowski]

Is libatasmart a going concern? The functionality overlaps with 
smartmontools, and the development seems to have stalled [1]. I 
originally started using libatasmart few years ago because it had better 
support for USB bridges, i.e. it allowed reading SMART data from USB 
external enclosures, which smartctl couldn't do at the time.


Recently, however, I ran into issues in skdump reading the SSD SMART 
attributes. I opened a bugzilla case [2], but there has been no traffic 
there.


Is there a reason for two SMART utilities?  I believe that the current 
smartctl functionality is a superset of libatasmart's. Are there 
capabilities in libatasmart that justify its separate existence?






[1] last commit on http://git.0pointer.de/?p=libatasmart.git is from 2 
years ago

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1103179
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Improving the state of ARM

[Matthew Garrett]

On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:

> In this case however I don't think much productive came from this
> discussion we had about hfsplus-tools.  Obviously no one wants
> hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
> to fix it.  So I think we should just drop it on ARM, and let anyone
> who wants it, fix it later (or reenable %{arm} if clang gets fixed).

Let me try this again. The aim is for Fedora to provide an experience 
that's consistent across primary architectures to the extent that is 
reasonably possible. If people don't care about that, we have a problem. 
The nature of that problem depends on who is failing to do the caring:

1) If the ARM maintainers don't care about ARM being equivalent to x86, 
that's a serious problem that is (with luck) easily fixable. On the 
other hand, if they care but don't have sufficient resources to fix 
things, that's a smaller problem but probably less easily fixed, 
because:

2) If individual package maintainers don't care about ARM, there's 
really not a lot we can do. They weren't involved in the decision to 
make ARM primary. They probably don't plan on installing Fedora on any 
ARM systems, so they gain no personal benefit from fixing it. What kind 
of incentives can we provide? Threaten to drop their packages? That 
would provide consistency, but it ends up being a rather limiting 
strategy.

Honestly the most practical solution would seem to be a concerted effort 
from the ARM team to fix these up - the assumption that individual 
package maintainers will take care of things isn't realistic. But given 
that they're busy getting arm64 into a good state, I don't know how 
reasonable that is given the available resources.

I think there's a real problem if ARM continues to languish behind x86's 
feature set, and I think it's realistic to ask whether that problem is 
sufficiently serious for demoting it. But that's clearly not the most 
desirable outcome, and so I'd really prefer us to figure out a way to 
fix things. Improving code portability benefits us, our users and the 
ecosystem as a whole.

-- 
Matthew Garrett | mj...@srcf.ucam.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: 19->20 fedup-0.8.0-4.fc19 messages worrisome?

[Adam Williamson]

On Sat, 2014-05-03 at 05:21 -0400, Felix Miata wrote:
> Does what follows suggest to not proceed with to reboot the fedup grub stanza?
> 
> setting up system for upgrade
> Finished. Reboot to start upgrade.
> Packages without updates:
>compat-libstdc++-33
>fedup
>firefox # versionlock set to avoid australis/FF29
>kernel-PAE 3.11.10
>kernel-PAE 3.13.9
>libgssglue
>python-urlgrabber
> 
> WARNING: problems were encountered during transaction test:
>broken dependencies
>  firefox 25 requires xulrunner 25
>package conflicts
> Traceback (most recent call last):
>File "/bin/fedup", line 239, in 
>  main(args)
>File "/bin/fedup", line 219, in main
>  for line in s.format_details():
> AttributeError: 'ProblemSummary' object has no attribute 'format_details'
> 
> 
> As I'm doing this on a clone partition, I can start over as a troubleshooting 
> exercise if necessary.

Late reply, but as no-one else replied...

It looks to me like there's a fedup bug there: it's crashing when trying
to tell you what package conflicts it found (because it's expecting
ProblemSummary to have a 'format_details' attribute, but it doesn't, so
boom).

So you know three things:

1) You've found a bug in fedup.
2) You definitely have a dep issue with your firefox version pinning
(though that's not really a showstopper, you could probably resolve it
somehow post-upgrade if it were the only problem)
3) You probably have a package conflict issue of some kind, but you
don't know what it is

Given 3), I'd be loath to run the upgrade. I'd report the bug in fedup
(to RH Bugzilla or to https://github.com/wgwoods/fedup , I don't know
which wwoods would prefer). Run it with its debug parameters and stuff
enabled, so hopefully there'll be enough information for Will to figure
out what's going wrong.

You could either wait for wwoods to fix the bug so you can find out what
the package conflict issue is, or you could twiddle with the installed
package set and versionlock configuration and see if you can come up
with a layout which doesn't cause fedup to crash, because it doesn't
have whatever package consistency issue is causing it to hit the crash
in the first place...
-- 
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: Make fails with fedora build options set

[Adam Williamson]

On Fri, 2014-05-02 at 07:07 +0200, Stanislav Ochotnicky wrote:
> On Thu 01 May 2014 01:34:43 PM CEST Jon Kent wrote:
> > Hi,
> >
> > I'm trying to get a GnuBatch package into Fedora, which is currently
> > being reviewed. One of the points raised in the review was that I was
> > running make without any Fedora options. I've added these as requested
> > so the make line now looks like:
> >
> > make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir}
> >
> > This expands out to :
> >
> > make -j4 CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
> > -m64 -mtune=generic" BINDIR=/usr/bin
> >
> > However with these options the build is now failing where is was working
> > fine before using just make. The errors are related to being unable to
> > find the header files (i.e. config.h). I've tried added -I option
> > pointing to the header directory but this did not help.
> >
> > What I don't understand is why this worked before, where as with these
> > make options set the build now fails. Any pointers much appreciated as
> > I'm just going in circles here trying to resolve this problem.
> >
> > The below is an part of the output I get when this fails:
> >
> > make[4]: Entering directory
> > `/home/jon/rpmbuild/BUILD/gnubatch-1.10/util'
> > gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
> > -m64 -mtune=generic   -c -o helpparse.o helpparse.c
> > helpparse.c:18:20: fatal error: config.h: No such file or directory
> >  #include "config.h"
> 
> Another (relatively common) problem is the parallelization (-j4)
> tripping the makefile up. I.e. dependencies for some targets are
> incomplete and config.h is not yet generated when they execute.

Any time this turns out to be the problem, add a comment explaining that
parallel build is disabled because it causes problems. Otherwise, when
someone else comes to handle the .spec, they won't be sure whether
parallel make not being used is simply a mistake or an oversight, and
may enable it, breaking things again.
-- 
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: NetworkManager-0.9.95 update in rawhide

[Dan Williams]

On Tue, 2014-06-10 at 21:37 +0400, Igor Gnatenko wrote:
> On Tue, Jun 10, 2014 at 9:34 PM, Thomas Haller  wrote:
> > On Tue, 2014-06-10 at 21:25 +0400, Igor Gnatenko wrote:
> >> Hi,
> >>
> >> After latest update i can't use my wifi in NM. Probably this bug not
> >> in NM, but I don't know how to debug this :(
> >
> > Do you have the package NetworkManager-wifi installed?
> no. Interesting.
> >
> > Check with
> > $ yum list NetworkManager-wifi
> >
> >
> > and you certainly need it. Actually, you should have gotten it
> > automatically...
> What's happens? Checking dnf logs.

As Igor and I discussed on IRC, the new NetworkManager package and
sub-packages include "Obsoletes: NetworkManager < 1:0.9.9.95-1" which
should cause *all* the subpackages (including NetworkManager-wifi) to
replace the previous packages, and thus NM-wifi should be installed.
We're checking with dnf people to figure out why this doesn't seem to be
the case.  I tested with 'yum' and a local repo before building the F21
update and this worked correctly, so at the moment the issue seems to be
with dnf.

Dan

-- 
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: F21 Self Contained Change: Remote Journal Logging

[Adam Williamson]

On Fri, 2014-05-02 at 17:51 +0200, Zbigniew Jędrzejewski-Szmek wrote:

> > It's kind of implicit in the Change proposal. When you submit a
> > Change, you are indicating that you want this to be something that
> > Fedora promotes (both from an engineering standpoint and a marketing one).

> I modifed the Change text to indicate that it is an alternative to
> exisiting solutions, and can be used in parallel.

Just as a note for future messaging purposes: the Server product's tech
spec explicitly nominates rsyslog as the supported remote logging
mechanism for Server. We did explicitly choose between rsyslog and the
new native systemd capability, and chose rsyslog at least until the
native systemd capability is a bit more mature.

No specific immediate impact or 'required action' here, just wanted to
note it for anyone following this discussion for purposes of future
public communication.
-- 
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: How to troubleshoot build flags

[Richard Shaw]

Still not quite ready to call this solved even though I got the "why"...

f2py will let LDFLAGS override the default built-in linker flags from
"linker_exe" and "linker_so". I would think at a minimum you would want it
as an append, not an override if not outright ignore the environment
variables for this specific case.

$ f2py3 -c --help-fcompiler
Gnu95FCompiler instance properties:
[SNIP]
  linker_exe  = ['/usr/bin/gfortran', '-Wall', '-Wall']
  linker_so   = ['/usr/bin/gfortran', '-Wall', '-Wall', '-shared']

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

Re: help needed to find a bug in zorba (or gcc 4.9)

[Jerry James]

On Tue, Jun 10, 2014 at 6:16 AM, Martin Gieseking
 wrote:
> Hi,
>
> I've tried to fix the broken zorba package in rawhide for a couple of weeks
> now but, unfortunately, without much success. The upstream developers don't
> seem to be able to find the cause for the issue either.
>
> The problem is that the package fails to build with gcc 4.9.0 (all archs)
> because the generated zorba binary segfaults for some queries due to
> accessing already freed memory. The issue only occurs with optimized builds
> (-O1, -O2, -O3) using gcc 4.9.0. With gcc 4.8.x the binary and thus the
> whole package build and work correctly. Therefore, it might also be possible
> that there's a bug in gcc's optimizer, but I'm not sure.
>
> valgrind and gcc's address sanitizer report the code sections where the
> error occurs but when stepping through them with a debugger, I'm unable to
> understand what's actually going on there. It looks as if the affected code
> should work properly. So I got stuck now.
>
> It would be great if someone could help to track down the issue in order to
> keep the package available in Fedora.

Here's the first problem pointed out by valgrind:
- class Store (src/store/naive/store.h) has a public member "zstring theEmptyNs"
- that object is set to a string that is also added to "StringPool
*theNamespacePool" inside Store::init() (src/store/naive/store.cpp)
- when the ZorbaImpl destructor runs on the singleton ZorbaImpl
object, it starts this call chain:
  o shutdownInternal(false)
  o StoreManager::shutdownStore(&GENV_STORE)
  o SimpleStore::shutdown(false)
  o Store::shutdown(false)
- Since theNamespacePool is non-NULL, we do this:
  theEmptyNs.~zstring();
  theXmlSchemaNs.~zstring();
  delete theNamespacePool;
  theNamespacePool = NULL;

We deleted theEmptyNs ... but left it sitting in theNamespacePool.  So
when theNamespacePool's destructor runs, it examines that string,
leading to the crash.  The same thing happens with theXmlSchemaNs.
The fix is to remove those strings from the StringPool instead of
explicitly deallocating them, and then let the Store destructor
actually delete the two strings, like so:

--- src/store/naive/store.cpp.orig 2013-11-06 00:20:44.0 -0700
+++ src/store/naive/store.cpp 2014-06-10 12:00:00.0 -0600
@@ -333,8 +333,8 @@

 if (theNamespacePool != NULL)
 {
-  theEmptyNs.~zstring();
-  theXmlSchemaNs.~zstring();
+  theNamespacePool->erase(theEmptyNs);
+  theNamespacePool->erase(theXmlSchemaNs);

   delete theNamespacePool;
   theNamespacePool = NULL;

Unfortunately, it appears that that is not the only bug.  Valgrind
shows at least two more bugs, both also tied into SimpleStore and
Store somehow, but I'm out of time to look at them.

Off topic: the check for unicode/coll.h (ZORBA_HAVE_COLL_H) is failing
spuriously because CHECK_INCLUDE_FILES is used where
CHECK_INCLUDE_FILE_CXX should be used.  One fix is to do this in
%prep:

# Fix detection of unicode/coll.h
sed -i 's,\(CHECK_INCLUDE_FILE\)S\( ("unicode/coll.h"\),\1_CXX\2,'
CMakeLists.txt

Good luck and regards,
-- 
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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Matthew Garrett]

On Tue, Jun 10, 2014 at 07:11:53PM +0100, Matthew Garrett wrote:
> On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:
> 
> > In this case however I don't think much productive came from this
> > discussion we had about hfsplus-tools.  Obviously no one wants
> > hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
> > to fix it.  So I think we should just drop it on ARM, and let anyone
> > who wants it, fix it later (or reenable %{arm} if clang gets fixed).
> 
> If the Fedora/ARM community don't care about feature parity with x86, 
> then we should just drop them back to secondary status.

That was overly critical of me and did nothing to actually further the 
discussion. I apologise.

-- 
Matthew Garrett | mj...@srcf.ucam.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

ExcludeArch tracker doesn't appear to be effective

[Matthew Garrett]

https://bugzilla.redhat.com/show_bug.cgi?id=485251 is depressing. Nine 
bugs have been closed - of these, one is a review request that was 
dropped, two were incorrectly closed after an ExcludeArch was added and 
one was closed as a duplicate. Further, one bug was just unsubscribed 
from the tracker after tests were disabled. We've correctly fixed *five* 
packages that have been flagged as FTBFS on ARM. At this rate of fixing, 
and given the rate at which new bugs are added, ARM will never build the 
entire archive.

Fedora is supposed to provide a consistent experience across primary 
architectures. Having a subset of our packages fail to build on ARM 
means that's not true, and the current state of affairs clearly violates 
point 8 of the architecture promotion requirements. How can we fix this?

-- 
Matthew Garrett | mj...@srcf.ucam.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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Matthew Garrett]

On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:

> In this case however I don't think much productive came from this
> discussion we had about hfsplus-tools.  Obviously no one wants
> hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
> to fix it.  So I think we should just drop it on ARM, and let anyone
> who wants it, fix it later (or reenable %{arm} if clang gets fixed).

If the Fedora/ARM community don't care about feature parity with x86, 
then we should just drop them back to secondary status.

-- 
Matthew Garrett | mj...@srcf.ucam.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: How to troubleshoot build flags

[Richard Shaw]

Ok, I figured out the problem but not WHY it's a problem but basically it
doesn't like the linker flag "-Wl,-z,relro". I actually had to patch the
makefile for this so it wouldn't get applied to the f2py command but
apparently it was still casing a linker issue for some reason.

The workaround (I won't call it a solution) was to add "unset LDFLAGS"
after %configure but before make.

The interesting part is that it still seems to be applied to most of the
gfortran lines (pulled in by configure into the makefile) but there must be
some place that it was being pulled in by the environment variable, which
is why it would fail from rpmbuild but pass by running make manually.

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

Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Richard W.M. Jones]

On Tue, Jun 10, 2014 at 06:53:59PM +0100, Matthew Garrett wrote:
> On Tue, Jun 10, 2014 at 06:44:06PM +0100, Richard W.M. Jones wrote:
> > On Tue, Jun 10, 2014 at 06:39:52PM +0100, Matthew Garrett wrote:
> > > Ok. Once the build's done let's remove the ExcludeArch so it continues 
> > > to show up as a failure in mass builds. It can be restored if we 
> > > actually need to make any code changes.
> > 
> > Where is the Fedora policy that we should break builds so that we can
> > collectively remember there is a bug in a particular architecture?
> > That's what Bugzilla is for.
> 
> Having it show up on the FTBFS list sparked a discussion that noted 
> upstream movement on this. If it hadn't been there we wouldn't have 
> noticed, and even once LLVM is fixed this would probably have remained 
> ExcludeArch: arm.

I do think we should have a better way to track bugs in Bugzilla.  It
is a place where bugs often go to die, because it lacks any useful
search function or overview mechanism.

In this case however I don't think much productive came from this
discussion we had about hfsplus-tools.  Obviously no one wants
hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
to fix it.  So I think we should just drop it on ARM, and let anyone
who wants it, fix it later (or reenable %{arm} if clang gets fixed).

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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Matthew Garrett]

On Tue, Jun 10, 2014 at 06:44:06PM +0100, Richard W.M. Jones wrote:
> On Tue, Jun 10, 2014 at 06:39:52PM +0100, Matthew Garrett wrote:
> > Ok. Once the build's done let's remove the ExcludeArch so it continues 
> > to show up as a failure in mass builds. It can be restored if we 
> > actually need to make any code changes.
> 
> Where is the Fedora policy that we should break builds so that we can
> collectively remember there is a bug in a particular architecture?
> That's what Bugzilla is for.

Having it show up on the FTBFS list sparked a discussion that noted 
upstream movement on this. If it hadn't been there we wouldn't have 
noticed, and even once LLVM is fixed this would probably have remained 
ExcludeArch: arm.

-- 
Matthew Garrett | mj...@srcf.ucam.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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Richard W.M. Jones]

On Tue, Jun 10, 2014 at 06:39:52PM +0100, Matthew Garrett wrote:
> On Tue, Jun 10, 2014 at 06:34:31PM +0100, Richard W.M. Jones wrote:
> 
> > The bug that I'm actually fixing is that we haven't had a successful
> > hfsplus-tools build in nearly a year.
> 
> Ok. Once the build's done let's remove the ExcludeArch so it continues 
> to show up as a failure in mass builds. It can be restored if we 
> actually need to make any code changes.

Where is the Fedora policy that we should break builds so that we can
collectively remember there is a bug in a particular architecture?
That's what Bugzilla is for.

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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Matthew Garrett]

On Tue, Jun 10, 2014 at 06:34:31PM +0100, Richard W.M. Jones wrote:

> The bug that I'm actually fixing is that we haven't had a successful
> hfsplus-tools build in nearly a year.

Ok. Once the build's done let's remove the ExcludeArch so it continues 
to show up as a failure in mass builds. It can be restored if we 
actually need to make any code changes.

-- 
Matthew Garrett | mj...@srcf.ucam.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: NetworkManager-0.9.95 update in rawhide

[Igor Gnatenko]

On Tue, Jun 10, 2014 at 9:34 PM, Thomas Haller  wrote:
> On Tue, 2014-06-10 at 21:25 +0400, Igor Gnatenko wrote:
>> Hi,
>>
>> After latest update i can't use my wifi in NM. Probably this bug not
>> in NM, but I don't know how to debug this :(
>
> Do you have the package NetworkManager-wifi installed?
no. Interesting.
>
> Check with
> $ yum list NetworkManager-wifi
>
>
> and you certainly need it. Actually, you should have gotten it
> automatically...
What's happens? Checking dnf logs.
>
>
>
> Thomas



-- 
-Igor Gnatenko
-- 
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: koji uploads (for scratch builds) broken?

[Richard W.M. Jones]

On Tue, Jun 10, 2014 at 12:28:22PM -0500, Dennis Gilmore wrote:
> What version of koji do you have installed?

koji-1.9.0-1.fc20.noarch

However .. it just started to work again, so it must have been some
temporary weirdness.

Thanks,

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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Richard W.M. Jones]

On Tue, Jun 10, 2014 at 06:21:00PM +0100, Matthew Garrett wrote:
> On Tue, Jun 10, 2014 at 06:14:03PM +0100, Richard W.M. Jones wrote:
> > On Tue, Jun 10, 2014 at 06:00:05PM +0100, Matthew Garrett wrote:
> > > ExcludeArch implies that it's acceptable that it doesn't build on ARM 
> > > and removes the incentive for anyone to fix it. It's not.
> > 
> > There's a process for handling this, which is to create (if required)
> > a Fedora bug for the package, and then attach it to this tracker:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM
> > 
> > Then add ExcludeArch to the package, mentioning the particular bug.
> 
> I've never seen this actually result in the bug being fixed in leaf 
> packages.

The bug that I'm actually fixing is that we haven't had a successful
hfsplus-tools build in nearly a year.

However I think you're quite right that this is unlikely to fix the
LLVM on ARM bug.

> > I'm going to go ahead and do this now, since otherwise we won't have
> > hfsplus-tools at all for any user.
> 
> This is inappropriate. The bug is in LLVM, not hfsplus-tools. Quoting 
> from the guidelines:
> 
> "ExcludeArch should only be set when the architecture is not relevant 
> for the package, the package is non-functional on the architecture, or 
> the code does not compile cleanly for the architecture."
> 
> The code compiles fine, LLVM then fucks up linking.

It didn't even compile for me.  The error was:

  clang -g3 -Wall -fblocks 
-I/home/rjones/d/fedora/hfsplus-tools/master/diskdev_cmds-540.1.linux3/BlocksRunTime
 -I/home/rjones/d/fedora/hfsplus-tools/master/diskdev_cmds-540.1.linux3/include 
-DDEBUG_BUILD=0 -D_FILE_OFFSET_BITS=64 -D LINUX=1 -D BSD=1 -D 
VERSION=\"540.1.linux3\"   -c -o runtime.o runtime.c
  clang: warning: unknown platform, assuming -mfloat-abi=soft
  In file included from runtime.c:26:
  In file included from /usr/include/stdio.h:27:
  In file included from /usr/include/features.h:388:
  /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-soft.h' file not found
  # include 
^
  1 error generated.
  make[1]: *** [runtime.o] Error 1

The relevant bit of the package guidelines is this:

  If a Fedora package does not successfully compile, build or work on an
  architecture, then those architectures should be listed in the spec in
  ExcludeArch. Each architecture listed in ExcludeArch needs to have a
  bug filed in bugzilla, describing the reason that the package does not
  compile/build/work on that architecture. The bug number should then be
  placed in a comment, next to the corresponding ExcludeArch line.

which I've now done, and the package is now built in Rawhide:

  http://koji.fedoraproject.org/koji/taskinfo?taskID=7033081

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
-- 
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: koji uploads (for scratch builds) broken?

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 10 Jun 2014 17:43:37 +0100
"Richard W.M. Jones"  wrote:

> 
> I'm not sure if this is a local problem, but currently I'm unable
> to upload the SRPM to do a scratch build:
> 
> $ fedpkg srpm
> Wrote: 
> /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm
> $ koji build --scratch
> rawhide 
> /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm
> Uploading
> srpm: 
> /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm
> []  00% 00:00:00 0.00
> B- B/sec
> 
> At this point it hangs for a very long time, before eventually
> printing:
> 
> GenericError: upload path
> exists: 
> /mnt/koji/work/cli-build/1402417278.641677.KCBIWmof/libguestfs-1.27.14-3.fc21.src.rpm
> 
> I've tried this a few times, including bumping the release, but it
> fails in the same way each time.
> 
> Rich.
> 

What version of koji do you have installed?

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTl0A8AAoJEH7ltONmPFDREtYQAINhVGlyam0Hm4rinHxKmO2+
8NQ2ebHLzm1xWcZ24UIzQOvYbRqAqXx0hAaz/1uaAUOnVpp8Jcl0DlfPJstR7HIp
MMPUmK8QwVNeXfz6LCsbrAXyJbVAiQWkGLdx18DToCbddO+cP3C2CS8+Xq4+jKDx
/plRQDhn8iO03B1dbJwS1Xmz3OPtKus6joU8Pqyd5jl0rGNmuJkfVysQVrg+zYa+
ZaSnWcyTRPJrFbbnGU+MMhsQrB0pqStHhSoF8fP6LCwlY49SEoCQGzQ/ZbFGxvyx
/G/iejilVBET+s6cxeJybUspstm6ovymh7IHmFKfDxZ2RWNWdAhGyAMdTHaA7Rjr
ITl37PAwRWf+KN4JX1vHA5ngegXJ3v7b4gh9zKIkK/9pgulGG7a2hmsmkYVUrZWc
wmkF0kaBmC8nWpmnzny3y1UBLmRgCmA25yCa88Ej/ZQVOWJOdZjOhUfcKmGTeJq5
2Rcy1iK03OR8qZ0j+lMApEQr8tIsZZi/2ZmGEXNTDbEiROItTu2y9KGiHZ9suJq7
Xw34L1Nu2sfB8/xyrbjrHNmODXmFk6+sG5GZ8LYkSgDNh6zRQZhRFX6Mo6zu4MR8
c1pCLj/hAygzQmYj42uuFAoEFSIjHG85N2shLzpTX6VFBahWaUXuKuEgOxpwAF4C
E2HjISAt+UYZCv7JSr2k
=F0bO
-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

NetworkManager-0.9.95 update in rawhide

[Igor Gnatenko]

Hi,

After latest update i can't use my wifi in NM. Probably this bug not
in NM, but I don't know how to debug this :(

$ nmcli device status
DEVICE  TYPE  STATECONNECTION
virbr0  bridgeconnectedvirbr0
enp0s20u2   ethernet  connectedenp0s26u1u2
virbr0-nic  tap   connectedvirbr0-nic
cdc-wdm2gsm   unavailable  --
lo  loopback  unmanaged--
wlp3s0  wifi  unmanaged--

$ nmcli general
STATE  CONNECTIVITY  WIFI-HW  WIFI WWAN-HW  WWAN
connected  full  enabled  enabled  enabled  enabled

$ sudo iwconfig

wlp3s0IEEE 802.11abgn  ESSID:off/any
  Mode:Managed  Access Point: Not-Associated   Tx-Power=0 dBm
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Encryption key:off
  Power Management:off


Let me know what info is needed!
-- 
-Igor Gnatenko
-- 
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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Matthew Garrett]

On Tue, Jun 10, 2014 at 06:14:03PM +0100, Richard W.M. Jones wrote:
> On Tue, Jun 10, 2014 at 06:00:05PM +0100, Matthew Garrett wrote:
> > ExcludeArch implies that it's acceptable that it doesn't build on ARM 
> > and removes the incentive for anyone to fix it. It's not.
> 
> There's a process for handling this, which is to create (if required)
> a Fedora bug for the package, and then attach it to this tracker:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM
> 
> Then add ExcludeArch to the package, mentioning the particular bug.

I've never seen this actually result in the bug being fixed in leaf 
packages.

> I'm going to go ahead and do this now, since otherwise we won't have
> hfsplus-tools at all for any user.

This is inappropriate. The bug is in LLVM, not hfsplus-tools. Quoting 
from the guidelines:

"ExcludeArch should only be set when the architecture is not relevant 
for the package, the package is non-functional on the architecture, or 
the code does not compile cleanly for the architecture."

The code compiles fine, LLVM then fucks up linking.

-- 
Matthew Garrett | mj...@srcf.ucam.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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Richard W.M. Jones]

On Tue, Jun 10, 2014 at 06:00:05PM +0100, Matthew Garrett wrote:
> On Tue, Jun 10, 2014 at 05:23:01PM +0100, Richard W.M. Jones wrote:
> > On Tue, Jun 10, 2014 at 03:45:57PM +0100, Matthew Garrett wrote:
> > > Eh. We're constrained by our own policies here, not by anything 
> > > fundamental - LLVM being broken on ARM ought to mean that our ARM 
> > > product is worse, not that everything else is dragged down to the same 
> > > level.
> > 
> > So .. ExcludeArch %{arm} should be added?  I'm not clear what you're
> > saying here.
> 
> ExcludeArch implies that it's acceptable that it doesn't build on ARM 
> and removes the incentive for anyone to fix it. It's not.

There's a process for handling this, which is to create (if required)
a Fedora bug for the package, and then attach it to this tracker:

https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM

Then add ExcludeArch to the package, mentioning the particular bug.

I'm going to go ahead and do this now, since otherwise we won't have
hfsplus-tools at all for any user.

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

Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Matthew Garrett]

On Tue, Jun 10, 2014 at 05:23:01PM +0100, Richard W.M. Jones wrote:
> On Tue, Jun 10, 2014 at 03:45:57PM +0100, Matthew Garrett wrote:
> > Eh. We're constrained by our own policies here, not by anything 
> > fundamental - LLVM being broken on ARM ought to mean that our ARM 
> > product is worse, not that everything else is dragged down to the same 
> > level.
> 
> So .. ExcludeArch %{arm} should be added?  I'm not clear what you're
> saying here.

ExcludeArch implies that it's acceptable that it doesn't build on ARM 
and removes the incentive for anyone to fix it. It's not.

-- 
Matthew Garrett | mj...@srcf.ucam.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

koji uploads (for scratch builds) broken?

[Richard W.M. Jones]

I'm not sure if this is a local problem, but currently I'm unable
to upload the SRPM to do a scratch build:

$ fedpkg srpm
Wrote: /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm
$ koji build --scratch rawhide 
/home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm 
Uploading srpm: 
/home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm
[]  00% 00:00:00 0.00 B- B/sec

At this point it hangs for a very long time, before eventually printing:

GenericError: upload path exists: 
/mnt/koji/work/cli-build/1402417278.641677.KCBIWmof/libguestfs-1.27.14-3.fc21.src.rpm

I've tried this a few times, including bumping the release, but it
fails in the same way each time.

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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Richard W.M. Jones]

On Tue, Jun 10, 2014 at 03:45:57PM +0100, Matthew Garrett wrote:
> On Tue, Jun 10, 2014 at 07:54:26AM +0100, Richard W.M. Jones wrote:
> > On Mon, Jun 09, 2014 at 10:20:46PM +0100, Matthew Garrett wrote:
> > > On Mon, Jun 09, 2014 at 08:43:07PM +0100, Richard W.M. Jones wrote:
> > > 
> > > > Can we excludearch %{arm} for this one?
> > > 
> > > Why? It's a bug that it doesn't build on ARM. Refusing to build it 
> > > doesn't fix the bug, and then someone else will crash into the same 
> > > issue when they dare to build something that needs llvm.
> > 
> > It seems the alternative is hfsplus-tools doesn't work at all for
> > anyone.
> 
> Eh. We're constrained by our own policies here, not by anything 
> fundamental - LLVM being broken on ARM ought to mean that our ARM 
> product is worse, not that everything else is dragged down to the same 
> level.

So .. ExcludeArch %{arm} should be added?  I'm not clear what you're
saying here.

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

Re: How to troubleshoot build flags

[Richard Shaw]

On Tue, Jun 10, 2014 at 11:07 AM, Andrew Schultz 
wrote:

> Richard Shaw wrote:
>
>> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crt1.o: In
>> function `_start':
>> (.text+0x20): undefined reference to `main'
>> collect2: error: ld returned 1 exit status
>> rmbadname1: Replacing "len" with "len_bn".
>> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crt1.o: In
>> function `_start':
>> (.text+0x20): undefined reference to `main'
>> collect2: error: ld returned 1 exit status
>> error: Command "/usr/bin/gfortran -Wall -Wl,-z,relro -Wl,-z,relro
>> /tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/wmodule.o
>> /tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/fortranobject.o
>> /tmp/tmpom3x2m/wspr1.o /tmp/tmpom3x2m/getfile.o
>> /tmp/tmpom3x2m/paterminate.o /tmp/tmpom3x2m/audiodev.o
>> /tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/w-f2pywrappers.o
>> thnix.o libwspr.a -L/usr/lib64 -lfftw3f -lgfortran -lportaudio -lpthread
>> -lsamplerate -lpython3.3m -lgfortran -o ./w.cpython-33m.so
>> " failed with exit status 1
>>
>> make: *** [WsprMod/w.so] Error 1
>>
>
> It's using the gfortran to link and then explicitly adding -lgfortran
> (twice, of course);  gfortran will do this automatically.  Also, if a
> executable has a main method in C, then you'll be more successful linking
> the program with gcc instead of gfortran (if it has a main program in
> fortran, then use gfortran to link).  It might be possible to go the other
> way, but I have never had success.


None of the very few c files define main so I'm guessing it's defined in
the fortran code.

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

Re: How to troubleshoot build flags

[Andrew Schultz]

Richard Shaw wrote:

/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
rmbadname1: Replacing "len" with "len_bn".
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
error: Command "/usr/bin/gfortran -Wall -Wl,-z,relro -Wl,-z,relro
/tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/wmodule.o
/tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/fortranobject.o
/tmp/tmpom3x2m/wspr1.o /tmp/tmpom3x2m/getfile.o
/tmp/tmpom3x2m/paterminate.o /tmp/tmpom3x2m/audiodev.o
/tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/w-f2pywrappers.o
thnix.o libwspr.a -L/usr/lib64 -lfftw3f -lgfortran -lportaudio -lpthread
-lsamplerate -lpython3.3m -lgfortran -o ./w.cpython-33m.so
" failed with exit status 1
make: *** [WsprMod/w.so] Error 1


It's using the gfortran to link and then explicitly adding -lgfortran 
(twice, of course);  gfortran will do this automatically.  Also, if a 
executable has a main method in C, then you'll be more successful 
linking the program with gcc instead of gfortran (if it has a main 
program in fortran, then use gfortran to link).  It might be possible to 
go the other way, but I have never had success.


--
Andrew Schultz
aj...@buffalo.edu
http://www.cbe.buffalo.edu/schultz
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

How to troubleshoot build flags

[Richard Shaw]

Does anyone have a favorite method of figuring out what build flags are
causing an issue?

I'm trying to package WSPR[1] for the ham radio sig. It is autotools based
and when I use %configure the build fails but when I just use plain
configure it succeeds. It uses gfortran and f2py extensively which I think
is part of it.

The last command prior to the error is identical regardless of which
configure I use so I'm guessing the build flags for one of the input
objects to the gfortran linking phase is causing the issue.

Here's a snippet of the error although my question is how to troubleshoot
these types of problems in general:

/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
rmbadname1: Replacing "len" with "len_bn".
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
error: Command "/usr/bin/gfortran -Wall -Wl,-z,relro -Wl,-z,relro
/tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/wmodule.o
/tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/fortranobject.o
/tmp/tmpom3x2m/wspr1.o /tmp/tmpom3x2m/getfile.o
/tmp/tmpom3x2m/paterminate.o /tmp/tmpom3x2m/audiodev.o
/tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/w-f2pywrappers.o thnix.o
libwspr.a -L/usr/lib64 -lfftw3f -lgfortran -lportaudio -lpthread
-lsamplerate -lpython3.3m -lgfortran -o ./w.cpython-33m.so" failed with
exit status 1
make: *** [WsprMod/w.so] Error 1

Thanks,
Richard

[1] http://physics.princeton.edu/pulsar/K1JT/wspr.html
-- 
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: Self introduction: Dave Love

[Lubomir Rintel]

On Mon, 2014-06-09 at 22:48 +0100, Dave Love wrote:
> I've just submitted my first package, the procenv tool for showing the
> process environment:
> 
> 
> I have more to offer which are relevant to HPC or other research
> computing.  There's a collection of specs for packages I've installed at
> , although many of them will
> need re-doing for Fedora, and some aren't suitable.
> 
> I'm a sometime Emacs and GNU Fortran maintainer, and currently maintain
> the community version of the Grid Engine batch system.
> 
> FAS: loveshack; AKA f...@gnu.org

Welcome on board!

Lubo

-- 
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: Self introduction: Dave Love

[Orion Poplawski]

On 06/09/2014 03:48 PM, Dave Love wrote:
> I've just submitted my first package, the procenv tool for showing the
> process environment:
> 
> 
> I have more to offer which are relevant to HPC or other research
> computing.  There's a collection of specs for packages I've installed at
> , although many of them will
> need re-doing for Fedora, and some aren't suitable.
> 
> I'm a sometime Emacs and GNU Fortran maintainer, and currently maintain
> the community version of the Grid Engine batch system.
> 
> FAS: loveshack; AKA f...@gnu.org
> 

Dave -  Nice to see you joining the project!

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.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

Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Matthew Garrett]

On Tue, Jun 10, 2014 at 07:54:26AM +0100, Richard W.M. Jones wrote:
> On Mon, Jun 09, 2014 at 10:20:46PM +0100, Matthew Garrett wrote:
> > On Mon, Jun 09, 2014 at 08:43:07PM +0100, Richard W.M. Jones wrote:
> > 
> > > Can we excludearch %{arm} for this one?
> > 
> > Why? It's a bug that it doesn't build on ARM. Refusing to build it 
> > doesn't fix the bug, and then someone else will crash into the same 
> > issue when they dare to build something that needs llvm.
> 
> It seems the alternative is hfsplus-tools doesn't work at all for
> anyone.

Eh. We're constrained by our own policies here, not by anything 
fundamental - LLVM being broken on ARM ought to mean that our ARM 
product is worse, not that everything else is dragged down to the same 
level.

> BTW this package is also affected by the -fstack-protector-strong LLVM
> bug, but that is simple to work around.

Yeah that complaint is completely fair.

-- 
Matthew Garrett | mj...@srcf.ucam.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

Orphaning or Retiring SOAPpy

[Pierre-Yves Chibon]

Hi,

I am wondering if someone is interested in picking up the maintainance of SOAPpy
in Fedora.

The upstream we were following [1] is dead for a while. There are some forks
that seems to be moving forward but one would have to check which fork to go
with [2, 3, 4, ...].
In addition SOAPpy has currently two CVE bugs opened (#1094619, #1094620), for
which I do not know if any of the new upstreams has a fix or not.

Finally depend on SOAPpy:
$ repoquery --whatrequires SOAPpy
  python-twisted-web-0:12.2.0-3.fc20.x86_64
  pytrainer-0:1.9.1-5.fc20.noarch

Upstream of python-twisted suggested to drop SOAPpy as a dependency (and
possibly drop the module as well) [5], so only pytrainer might be problematic.

So if anyone is willing to maintain this package properly I will happily give it
a new home, otherwise I will orphan it and let it be retire with the F21
branching.


Thanks,
Pierre

[1] http://pywebsvcs.sourceforge.net
[2] https://github.com/kiorky/SOAPpy (which is the version published on pypi,
https://pypi.python.org/pypi/SOAPpy)
[3] https://github.com/pelletier/SOAPpy
[4] https://github.com/jeffkit/SOAPpy
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1094619#c6


pgp6NDYXNg72Z.pgp
Description: 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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 10 Jun 2014 07:48:36 +0100
"Richard W.M. Jones"  wrote:

> On Mon, Jun 09, 2014 at 02:22:57PM -0500, Dennis Gilmore wrote:
> > On Mon, 9 Jun 2014 17:08:13 +0100
> > "Richard W.M. Jones"  wrote:
> > > I have a Fedora 20 ppc64 Mac right next to my feet here that is
> > > definitely booting using yaboot.
> > 
> > Then you did not install using Fedora 20.
> 
> F20/Rawhide from DVD is uninstallable on these Macs.  I wish that were
> not so, but it is.  You have to go via the upgrade route from F19 or
> earlier.  I'm just saying it's a fact that I have a ppc64 machine that
> uses yaboot to boot into Fedora 20.
> 
> Rich.
> 

its a fact that there is no way to build a yaboot update period because
32 bit ppc has been dropped. I believe that apple and yellowdog ppc
hardware is not tested or supported by the ppc team. so you are very
much on your own there. just because you have an old build of a package
installed is not a valid reason to keep it active when it can not be
built or supported. any upgraded system will not automatically be
migrated over. 

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTlw+XAAoJEH7ltONmPFDRCQIP/jDwC7IGHj0V02ynnooJD08K
PmLJaox8ApAz53rs3JSC27z5SozbJrBrS+EJMAfdwWp8ub/VYn8ag7tLlR489GJ0
0oR+EicjQ1HrlHGFxYgO8C/NAgWtCMgpLIhmnqLzUcjpAz6lz8iDGnwUoxeIYdew
pzc54OpAqxDSXU8OXnb1DblxEa+WYn8RxYXlnyFTz/7gPELd6btjznYIRQC/tfgE
C8iXAnQOfU80rJT5l5FcSb1CRd6iGqgn1ZAh7PDH7W+cinSZn2d/+K1qChqwpPb6
nYZJw8sPojObv+RDQZKzqYdXR9+wR0NHe9wSFqIxbazf9Ybv+fn2Efk8oQwuhfSh
Ywb4srXRZBXJ43aSAhCJeMveNOQp+Ey6lYryEr/dwDi1lzp0XBk6hfTwi0gZqkJC
GtHQjMIA58u1OSlEWAktZAzc4sLEkHvHIbppzysmYEML6IYCJPt3JinUoJvmu9l0
tLxMHeFeGGquFBQlQpN1afVIXoWJ+X36IK+u4xTrJFOfwe/upf22mBi7ko01HOAm
VokF1Q9PntXSa6r2btfpnAEq3ix145ci9JqqZRMzpA+eovxI+CddY0YdcNiYr38+
7BApct1/KL/CcMofO4MUUB2GEXgUaI8bY2M7XbjT8z3KU0cS3dSbDEL+Jv8b4n3S
GeOLgIUdJyBvV4ExLrYu
=p2eF
-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: This Weeks FESCo Meeting: Cancelled

[Matthew Miller]

On Wed, Jun 04, 2014 at 12:51:34PM -0400, Peter Jones wrote:
> FWIW, I'm going to miss next week's meeting, as I'll be on vacation.

Me too, it turns out. (Sorry for the late notice; it's late-breaking plans.)

-- 
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: help needed to find a bug in zorba (or gcc 4.9)

[Martin Gieseking]

Am 10.06.2014 14:24, schrieb Petr Spacek:

On 10.6.2014 14:16, Martin Gieseking wrote:

The problem is that the package fails to build with gcc 4.9.0 (all archs)
because the generated zorba binary segfaults for some queries due to
accessing
already freed memory. The issue only occurs with optimized builds
(-O1, -O2,
-O3) using gcc 4.9.0. With gcc 4.8.x the binary and thus the whole
package
build and work correctly. Therefore, it might also be possible that
there's a
bug in gcc's optimizer, but I'm not sure.




Does it happen if you compile it *with* -fno-delete-null-pointer-checks
switch?

That one caused a lot of grief with BIND 9.



Yes, unfortunately, it does. I just rebuilt zorba with the suggested 
option but still get a buggy binary that segfaults while building the 
package.


Martin
--
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: help needed to find a bug in zorba (or gcc 4.9)

[Petr Spacek]

On 10.6.2014 14:16, Martin Gieseking wrote:

Hi,

I've tried to fix the broken zorba package in rawhide for a couple of weeks
now but, unfortunately, without much success. The upstream developers don't
seem to be able to find the cause for the issue either.

The problem is that the package fails to build with gcc 4.9.0 (all archs)
because the generated zorba binary segfaults for some queries due to accessing
already freed memory. The issue only occurs with optimized builds (-O1, -O2,
-O3) using gcc 4.9.0. With gcc 4.8.x the binary and thus the whole package
build and work correctly. Therefore, it might also be possible that there's a
bug in gcc's optimizer, but I'm not sure.

valgrind and gcc's address sanitizer report the code sections where the error
occurs but when stepping through them with a debugger, I'm unable to
understand what's actually going on there. It looks as if the affected code
should work properly. So I got stuck now.

It would be great if someone could help to track down the issue in order to
keep the package available in Fedora.

Here is the latest SRPM:
http://mgieseki.fedorapeople.org/review/zorba-3.0.0-4.fc21.src.rpm

The corresponding bug tickets can be found here:
https://bugzilla.redhat.com/show_bug.cgi?id=1095292
https://bugs.launchpad.net/bugs/1317976

Thanks,
Martin


Does it happen if you compile it *with* -fno-delete-null-pointer-checks switch?

That one caused a lot of grief with BIND 9.

--
Petr^2 Spacek
--
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: Firefox Gtk3 test package

[Martin Stransky]

On 06/09/2014 09:04 PM, Kẏra wrote:

On that note, I haven't seen a new build in a while! When can we hope for
an update?


There are some patches waiting upstream for review so when those are
done. I'd like also update the firefox-gtk3 build to Firefox 31.



cool! can you link to bugs / review pages for those patches so that we can
track their progress? updating the build to FF31 also sounds great [=


FF31 is out of nightly and FF32 has already been there for well over a month
now and FF33 will hit nightly tomorrow! Will the gtk3 build be updated again
soon?


Yes, I'm going to update it this week, after Firefox 30 release. The 
firefox-gtk3 is always latest trunk, the version is just for orientation 
(It's FF32 now).


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

help needed to find a bug in zorba (or gcc 4.9)

[Martin Gieseking]

Hi,

I've tried to fix the broken zorba package in rawhide for a couple of 
weeks now but, unfortunately, without much success. The upstream 
developers don't seem to be able to find the cause for the issue either.


The problem is that the package fails to build with gcc 4.9.0 (all 
archs) because the generated zorba binary segfaults for some queries due 
to accessing already freed memory. The issue only occurs with optimized 
builds (-O1, -O2, -O3) using gcc 4.9.0. With gcc 4.8.x the binary and 
thus the whole package build and work correctly. Therefore, it might 
also be possible that there's a bug in gcc's optimizer, but I'm not sure.


valgrind and gcc's address sanitizer report the code sections where the 
error occurs but when stepping through them with a debugger, I'm unable 
to understand what's actually going on there. It looks as if the 
affected code should work properly. So I got stuck now.


It would be great if someone could help to track down the issue in order 
to keep the package available in Fedora.


Here is the latest SRPM:
http://mgieseki.fedorapeople.org/review/zorba-3.0.0-4.fc21.src.rpm

The corresponding bug tickets can be found here:
https://bugzilla.redhat.com/show_bug.cgi?id=1095292
https://bugs.launchpad.net/bugs/1317976

Thanks,
Martin
--
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: Nonresponsive package maintainer: crystal

[Miloslav Trmač]

2014-06-10 0:18 GMT+02:00 Ben Nemec :

> I sent a message about this about six months ago too, and the situation
> hasn't changed since then:
> https://lists.fedoraproject.org/pipermail/devel/2013-December/192617.html
>

> I've tried additional ways to contact the maintainer since then, as
> noted in https://bugzilla.redhat.com/show_bug.cgi?id=1016943 and
> https://bugzilla.redhat.com/show_bug.cgi?id=1029728 but have had no
> response at all.
>

 It seems we in FESCo dropped the ball on this in December.  I’m sorry.

I would like to take over maintenance of this package.


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

Retire pywcs

[Sergio Pascual]

Hello,

I have retired pywcs in Rawhide. It FTBS in the last mass build, and
upstream recomends to switch to astropy anyway.

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

[Fwd: The Future of Irssi]

[Ankur Sinha]

FYI:

 Forwarded Message 
> From: Alexander Færøy 
> To: irssi-us...@dragoncat.net, irssi-...@dragoncat.net
> Cc: Irssi Staff 
> Subject: The Future of Irssi
> Date: Tue, 10 Jun 2014 10:27:11 +0200
> 
> Hello,
> 
> 
> Irssi hasn't been under active development for the last few years. We
> want to
> change that. To make it easier for new contributors to get involved
> and stick
> around, we moved to where most open source contributors are spending
> their
> time: the source is now maintained on Github.
> 
> 
> Contribution Model
> ==
> 
> 
> The repositories that are currently available at svn.irssi.org will,
> over a
> period of the next month, be migrated to our newly created Github
> organization
> (https://github.com/irssi). This means that no new commits will be
> made to our
> Subversion repositories and the Git repositories available on Github
> are from
> today the official way of getting the source code of Irssi. The
> primary Irssi
> client repository has already been migrated to Github and is available
> at
> https://github.com/irssi/irssi
> 
> 
> We will, starting today, expect contributors to fork the official
> Irssi
> repositories on Github, do their changes on a feature branch, and
> submit Github
> pull requests to us. The team will then review your changes and
> hopefully,
> together, we will be able to get your code into the official Irssi
> repository.
> This will make getting your contributions reviewed and merged smoother
> and it
> has the added benefit that your patches appears to be coming from you
> which in
> turn is helping to make the gap between being a core developer and a
> contributor close to non-existing.
> 
> 
> Issue Tracking
> ==
> 
> 
> This is one of the more controversial changes. Over time, you guys
> have
> submitted tons of bugs to our bug tracker at bugs.irssi.org only to
> see them
> rot.
> 
> 
> We will, starting today, stop using bugs.irssi.org and use Github's
> issue
> tracker instead.
> 
> 
> We have decided **not** to do any automated migration of the
> bugs.irssi.org
> database. We realize that if we migrate everything over to Github,
> 1:1, it will
> only end up rotting in two bug trackers rather than in just one.
> 
> 
> We hope to see interested contributors help us checking which bugs
> that are
> still affecting Irssi and resubmit them to our Github issue tracker.
> 
> 
> We will manually go over opened bugs that contains patches to ensure
> that no
> code is left behind in the old tracker.
> 
> 
> The bug tracker will remain online as a reference, but we will
> redirect to
> Github for people interested in reporting bugs.
> 
> 
> Scripts
> ===
> 
> 
> Submitting scripts is historically something you guys have been good
> at.
> 
> 
> The way submitting scripts is currently done is that you write an
> email to
> scri...@irssi.org and someone from our team will manually add the
> script to the
> website. We're well aware that we've lagged behind requests to add new
> scripts
> and update existing ones so we're hoping to improve that too.
> 
> 
> From now on, new scripts **must** be submitted, in a pull request, to
> the
> irssi/scripts repository (https://github.com/irssi/scripts). The
> repository
> contains a description on how to contribute.
> 
> 
> This will make it much easier for our contributors to both add and
> maintain
> their scripts in the repository. It will also make it a lot easier for
> us to
> review and get code into the repository.
> 
> 
> Scriptassist Users
> ==
> 
> 
> For users using `scriptassist.pl`, you can start using the new
> repository right
> away using:
> 
> 
> /set scriptassist_script_sources
> http://ghscripts.irssi.org/scripts.dmp
> 
> 
> Otherwise, you can wait a month and the website will be migrated and
> everything
> should be working as usual, without you having to touch anything.
> 
> 
> Official IRC Channels
> =
> 
> 
> We are moving the official development and user support channel to
> `#irssi` on
> freenode. Historically, we have had our official development channel
> on IRCnet,
> a social channel on EFnet and a user support channel on freenode, but
> we
> realize it makes more sense to keep everything together at freenode.
> 
> 
> Closing Words
> =
> 
> 
> The changes to our contribution model will also affect people who are
> pulling
> from Subversion or scripts.irssi.org automatically.
> 
> 
> **Access to our Subversion repositories will be revoked and the move
> of
> scripts.irssi.org to the new Github site will happen on July 31st,
> 2014.**
> Until then, neither of the two systems will be maintained and no new
> content
> will be published there.
> 
> 
> Until the migration to Github is completed, you can find our official
> script
> repository at http://ghscripts.irssi.org/.  tomaw will continue being
> in charge
> of scripts and will happily review your pull requests on Github.
> 
> 
> Feel free to reac