Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

2024-05-07 Thread Omair Majid
Hi,

Florian Festi  writes:

> If anyone has any objections or would like to exclude a package, please
> let me know.

Could you please exclude the .NET packages (dotnet6.0, dotnet7.0,
dotnet8.0)? dotnet8.0 shouldn't need a fix (and it doesn't appear in your
list). dotnet7.0 is already EOL/orphaned/retired. dotnet6.0 will go
through the same EOL/orphan/retiring process later this year. There's
little point changing it now.

Thanks!

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Is it possible (or a good idea) to add additional files to the -debuginfo packages?

2023-11-08 Thread Omair Majid
Hi,

"Richard W.M. Jones"  writes:

> Can you be a bit more specific?  What programming language?  What does
> the debug data look like?  Is it embedded in ELF sections?  What tools
> are needed / provided to extract it?  How does the debugger read it?

This is for the .NET ecosystem, where the primary languages include C#,
F# and VB.NET.

The compiled .NET code files are generally named along the lines of
Foo.dll, and debug data is stored in separate Foo.pdb files. The files
are generated by the .NET compilers directly. The Foo.dll file generally
contains a reference to where the .pdb files are stored (they could be
online, for example, - similar to a debuginfod server - or on the disk
next to the .dll file).

I am not aware of any non-.NET tools in Fedora that can work with these
files.

.NET-specific debuggers know how to find the .pdb files when they see a
.dll file. Generally, every IDE provides their own debugger (often
closed source). An open source debugger is available at
https://github.com/Samsung/netcoredbg/ and used by some
(non-Fedora-packaged) open source IDEs.

To circle back to my original question, the disk layout currently looks
something like this:

- /usr/lib64/dotnet/shared/$NAME/$VERSION/foo.dll
- /usr/lib64/dotnet/shared/$NAME/$VERSION/foo.pdb

I was thinking that it might be possible to put the .dll file in the
base package (eg, dotnet-runtime-8.0) and the .pdb file in the debug package
(eg, dotnet-runtime-8.0-debuginfo) somehow.

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Is it possible (or a good idea) to add additional files to the -debuginfo packages?

2023-11-07 Thread Omair Majid
Hi,

I am trying to enable debug information for a programming language that
produces debuginfo in a custom (non-DWARF) format. I was thinking that
adding that programming-language-specific debuginfo to existing
-debuginfo packages seems like a good idea.

(Is that a bad idea?)

Any suggestions on how I can add additional files to the auto-generated
-debuginfo packages (which already contain some useful DWARF debuginfo).

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Orphaned packages looking for new maintainers

2023-06-09 Thread Omair Majid
Hi,

Jens-Ulrik Petersen  writes:

> What would be really helpful is to know how it compares with other Naskh fonts
> like Paktype (current default) and Nafees, and even Noto Nastaliq Urdu
> (they are all in Fedora 38).

I lack the tools/skills/knowledge/jargon to describe the differences I
see. Is there a guide for n00bs where they can read up on what sort of
things to compare and how to describe those differences?

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Orphaned packages looking for new maintainers

2023-06-08 Thread Omair Majid
Hi,

Not an expert, just a casual Urdu speaker with a drive by contribution.
I don't write Urdu much these days but I can read it.

Akira TAGOH  writes:

> I have no idea if Noto Sans Arabic or Noto Naskh Arabic is qualified
> for Urdu and Punjabi.  Even though they have minimal coverage in
> fontconfig perspective, there might be minor differences which look
> strange for native speakers like punctuation marks in CJK etc.

I looked through the Urdu bits using
https://fonts.google.com/noto/specimen/Noto+Naskh+Arabic and things
generally look okay. All the letters used in Urdu (~40, which is more
than ~30 used in Arabic) seem to be present. The text is legible and
readable. I tried a few punctuation marks and they are getting rendered
in a way I can read it.

> If we are going to change, we need feedback then.
> For the last resort, I could take them over temporarily though, we
> definitely need some help from Urdu/Punjabi communities.

I am not part of these communities, maybe I should join?

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Omair Majid
Hi,

Omair Majid  writes:

> If/when RISC-V support lands in .NET (eg, minimum of
> https://github.com/dotnet/runtime/issues/36748), we could use those
> tools (with hopefully minimal changes) to cross compile .NET for RISC-V.
>
> I can ask IBM to prioritize making these tools public.

Sorry, my information was out of date.

It's already public here:
https://github.com/ppc64le/build-scripts/tree/master/d/dotnet7

The prereq_install scripts would probably need a s/ppc64el/riscv64/g for
it to work on RISC-V.

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Omair Majid
Hi,

Thanks your thoughts!

Neal Gompa  writes:

> That's actually a lot better than it was when I helped with dotnet
> package review and bootstrap with 3.1.

Heh. That's very true! 3.1 had at least two source packages that had to
be kept in sync. I think you seemed much happier with the 7.0 review?
https://bugzilla.redhat.com/show_bug.cgi?id=2142178

> The main worry I have is how we're going to be able to build dotnet
> for a new architecture when nothing exists. RISC-V is the next big
> architecture, but the build for that will be difficult.

I am working with some folks from IBM on this who have had to build .NET
on s390x and ppc64le recently. Just like RISC-V, nothing existed for
those architectures before IBM started working on it. IBM have some
tools to automate this now. They are working on sharing the tools (and
their s390x, ppc64le builds) publicly, but there are some non-technical
blockers that prevent them.

If/when RISC-V support lands in .NET (eg, minimum of
https://github.com/dotnet/runtime/issues/36748), we could use those
tools (with hopefully minimal changes) to cross compile .NET for RISC-V.

I can ask IBM to prioritize making these tools public.

> It would also be good to have packaging guidelines for .NET
> applications, since there's a number of server and desktop Linux apps
> written in .NET languages that people would want to bring to Fedora.

I don't have a great solution for this. There are a few problems here:

- .NET applications really, really aren't meant to be built offline.
  Like other package ecosystems (eg, npm) every .NET application has a
  ton of dependencies fixed at specific versions. And they are fetched
  from the internet. There's no clear way to break down the dependency
  tree so we can start this work.

- Unlike ecosystems such as npm where everyone publishes source, .NET
  packages are binaries without a clear way to go from source -> binary.
  So even if we could figure out a clear way to slices the dependency
  tree so we can start building the root packages, it would be a manual
  process build every package

  - A subproblem is that lots of libraries only support building on
Windows, or through Visual Studio only. We would have to create/port
the upstream build scripts.

- GUI applications are simply not supported on Linux. .NET has no
  implementation for this. If you try and use the .NET SDK to build
  something that uses the GUI APIs, it will simply error out.

There's more discussion upstream at
https://github.com/dotnet/core/issues/7443 and
https://github.com/dotnet/source-build/discussions/2960

As a result of this, I am not sure where to even begin thinking about
packaging applications :(

Do you have any suggestions on the most important/useful applications
that we should look at for prototyping this effort?

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Omair Majid
Hey,

Neal Gompa  writes:

> Keep in mind that this isn't exactly the first time we've done this
> either: the .NET runtime is similarly screwy for its bootstrap
> process, and that's split across a couple of source packages.
>
> At this point, we hold our noses and hope for the best. At least
> there's a chance to reduce the pain with .NET over time as the Red Hat
> .NET folks work to improve upstream. There's basically zero chance for
> improvement with OpenJDK because of the nature of the upstream and how
> old and crufty they are.

I know it's tangential to the main discussion, but since .NET was called
out by name, I would like to get your thoughts on this. What would you
say are the biggest concerns with the .NET setup?

Here's how I understand the current state. There's a single source
package for each major version of .NET (dotnet6.0, dotnet7.0.). That
source is compiled into the complete .NET SDK+Runtime for each version.
There are no source or binary dependencies between versions. Each
version is built/updated independently. Only the first build for each
major version requires a full bootstrap (using prebuilt binaries), but
that's a one time. Subsequent builds of each .NET major version use the
previous build of that major version of .NET.

With that context, what primary concerns do you think we should be
focusing on?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: SPDX Statistics - University of Constantinople edition

2023-02-28 Thread Omair Majid
Hi,

Miroslav Suchý  writes:

> The list of packages needed to be converted is again here:
>
> 
> https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt
>
> List by package maintainers is here
>
>
> https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt

One package that I care about (`dotnet7.0`) was added to Fedora after
the Let's-move-Fedora-to-SPDX decision was finalized. So the package has
been using SPDX identifiers since the original package review.

How do I make sure such a package is recognized as converted-to-SPDX?

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Fedora 37 mass rebuild complete

2022-07-26 Thread Omair Majid

Kevin Fenzi  writes:

> Failures can be seen
> https://kojipkgs.fedoraproject.org/mass-rebuild/f37-failures.html

dotnet-build-reference-packages and dotnet3.1 have a cyclic build
dependency on each other. dotnet3.1 was intentionally retired. This
package should have been retired along with it. Done now:

https://src.fedoraproject.org/rpms/dotnet-build-reference-packages/c/f9874ae6c13e6db7e534d77d08502127df1594f2?branch=rawhide

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-25 Thread Omair Majid
Hi,

Ben Beasley  writes:

> However, dropping the -devel package is almost as drastic as simply
> retiring the OpenSSL 1.1 package altogether. Grepping spec files for
> 'BuildRequires:.*openssl1' turns up the following packages that would
> immediately FTBFS:
> ...
> - dotnet3.1
> ...

This package is already dropped from Rawhide. Upstream will drop all
support for .NET Core 3.1 (dotnet3.1) at the end of this year [1]. The
next version, .NET 6 (packaged as dotnet6.0), already builds and runs
against OpenSSL 3.0 as well.

[1] 
https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#lifecycle

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Omair Majid
Hi,

"jiri vanek"  writes:

> As for .NET - you can not compare.

That's completely fair. One (OpenJDK) has been open source in various
forms for 15 years. The other has been (re-designed and made) open
source for around 5 years now. 10 years is an eternity, and has both
positive and negative implications for the late-comer.

So there are definitely going to be huge differences, in terms of
ownership models, community contributions, availability, usage, how the
ecosystem works and user experience.

> The pure fact that you can dnf install it says nothing about what lies
> beneath and how to properly toolchain it or package applications for
> it. I had seenboth .NET packagin internals, and tried to pack and .NET
> application and it was terrible. But yes, presentation is good.

Could you share more?

Are your concerns around the .NET SDK/Runtime packages themselves or
packaging external applications that need to be built using the
SDK/Runtime?

What would make you revise your opinion?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Omair Majid
Hi,

Neal Gompa  writes:

> The Python team made "Fedora Loves Python": https://fedoralovespython.org/
> The .NET team maintains the Developer page for .NET and has a domain
> redirect to it: https://fedoraloves.net/

For the record, the .NET SIG has a bus factor of one (maybe two) people
when it comes to marketing like fedoraloves.net. We are probably going
to lose one person soon, and I don't know if we can dedicate the
manpower it needs anymore.

What do other communities that are short on members do? Are there
well-known strategies on how to best utilize the minimal people/time for
maximum community benefit?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-11 Thread Omair Majid
Hi,

Daniel P. Berrangé  writes:

> One way to reduce this burden is to not introduce new JDKs to all
> existing Fedora streams, only add it to rawhide so certification is
> only needed once.
>
> Having said that I'm still not clear on the real impact of the
> certification. Presumably thue certification is not re-done in each
> JDK RPM re-build, nor on every RPM re-build of a library it depends
> on.  If so, then do we really need to do certification for every
> Fedora release stream when adding a new JDK. Can we do a build for
> 35, certify it, and then do what is effectively no-change import
> and rebuild for 36/37-rawhide and just consider the 35-certification
> to cover those streams.

As I understand it, the certification (TCK) is only done on a binary
level, and only applies to the OpenJDK package itself. It's not a
one-time thing when a new version of the OpenJDK is added; it needs to
be re-done on every single rebuild and/or update of OpenJDK.

AFAIK, even if you rebuild the exact same sources with the exact same
toolchain with the exact same compiler flags, you still can't claim TCK
certification status from one build carries over to the next.

If we import a binary (RPM) from one Fedora version to the other, then
we can continue claiming that the original binary is still certified.

Please note that it has been more than 5 years since I was last involved
with Java, so things might have changed. I might also be mis-remembering
something. But hopefully that gives some context on why the
certification (TCK) burden is so huge.

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-10 Thread Omair Majid
Hi,

Ben Cotton  writes:

> According to short investigations, there are already precedents, where
> certification is a reason to build once, certificate, and repack.

This sounds fascinating. Can anyone share details about this? On the
surface, building something once and packaging that up for all Fedora
versions in an RPM sounds like it would violate all the guidelines under

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

Is there a sense of what defines "certification" in this context? What
would it take for a random package $foo to meet this threshold and claim
it needs to avoid rebuilding for certification?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Intro & Sponsor Request

2022-02-15 Thread Omair Majid
Hi,

Chris via devel  writes:

> I'm the package maintainer for Lutris that Steve has been in contact
> with. I'm unfortunately not qualified to sponsor him myself, so we
> need someone else to take him on as a sponsor.
>
> Steve seems quite engaged and capable of figuring things out himself,
> and whoever formally sponsors him will quite likely need to do very
> little work in their role as sponsor, both because of how engaged he
> is, and because I've already begun sponsoring him in an unofficial
> manner.

Have you seen
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#become_a_co_maintainer
 ?

It's a separate path to becoming a packager. You can onboard them as a
co-maintainer of an existing package. It sounds like a good match for
your situation.

Cheers,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Orphaning javahelp2

2022-02-07 Thread Omair Majid

Hi,

I have just orphaned javahelp2:

https://src.fedoraproject.org/rpms/javahelp2

As far as I can tell, nothing needs it:

$ repoquery -q --repo=rawhide{,-source,-modular} --whatrequires '*javahelp*'

Upstream has been dead for years and the last commit was in 2017:
https://github.com/javaee/javahelp/

javahelp2 implements a Java Swing Platform Look and Feel - which
requires access to internal APIs and those have been strongly
encapsulated and locked down in OpenJDK 17. It now fails to build from
source and will probably need extensive changes to build from source.

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: cmake on Rawhide is broken

2021-12-03 Thread Omair Majid
Hi,

Vitaly Zaitsev via devel  writes:

> /usr/bin/cmake: error while loading shared libraries:
> libcrypto.so.1.1: cannot open shared object file: No such file or
> directory

As a workaround, can you try a BuildRequires of `openssl1.1`? That
should get the libraries and let cmake proceed.

My scratch build with the added BuildRequires:

https://koji.fedoraproject.org/koji/taskinfo?taskID=79546890

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: ocaml binary hardening upstream questions

2021-10-22 Thread Omair Majid
Hi,

I will take a shot at answer some of these, with the caveat that I am
not too familiar with this either. My answers could be completely wrong.

"Richard W.M. Jones"  writes:

> On Fri, Oct 22, 2021 at 02:22:22PM +0100, Richard W.M. Jones wrote:
>>
>> I could use some help on this thread about Fedora hardening flags and
>> getting them right for OCaml code:
>>
>> https://github.com/ocaml/ocaml/issues/8648

Did you know that missing cf-protection support is okay in terms of
functionality but incomplete support is not? cf-protection is a feature
enabled when both the processor and the process claim they have
cf-protection support. If either of them is missing that support, the
application will still run fine (cf-protection is disabled). If both of
them claim cf-protection support, but the cf-protection implementation
in the application is incomplete (eg, missing endbr assembler
instructions) the application will fail at runtime.

> I should have been more specific so people don't have to search the
> messages.  Here are some questions:
>
> (1) Should we add annotations to assembler (*.S) files?

Yes. assembler files need two sets of modifications, in general:

- Adding `endbr` and friends at valid targets of indirect branches. When
  a CPU/process combination with CET/cf-protection enabled encounters an
  indirect branch, a missing endbr at the target will make it abort.

- Adding a .gnu.property.note to mark that the assembly has all the
  changes needed to enable cf-protection.

> (2) If (1), then what annotations precisely should we add and how?

Here's what these two sets of changes looked like for a tiny assembly
file I was playing around with:
https://github.com/dotnet/runtime/issues/40100#issuecomment-713882012
The changes did not get merged/reviewed; there might be bugs in my
prototype.

> (4) (Big ask) What do we need to do to enable cf-protection in
> the compiler?

I think this would be the same set of changes that you do manually in
(1)? Emitting endbr64 at the right places and placing the property note
in any generated files?

Then again, I spoke with some Java folks at a few years ago about this
and they pointed out that if the programming language itself provides
strong guarantees that prevent the security exploits that cf-protection
guards against, there's little need to fix the language compiler to emit
the endbr instructions. If OCaml code isn't vulnerable to
return-oriented-programming and similar attacks, cf-protection would be
of limited benefit.

Cheers,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36

2021-09-08 Thread Omair Majid
Hi,

Sahana Prasad  writes:

> An update that I will directly bring in the OpenSSL 3.0.0 final RC
> (released upstream yesterday)

Thanks for doing this!

I read the upstream announcement and it certainly reads like it's the
final/GA release, not an RC:

https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/

Do you know what's going on? Did they phrase it badly or did they
perform multiple releases in parallel?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Rebuilding packages that use std::call_once from libstdc++

2021-03-31 Thread Omair Majid
Hi,

Jonathan Wakely  writes:

> On 31/03/21 11:46 +0200, Florian Weimer wrote:
>>I do not see such symbol references for dotnet5.0.  I have
>
> Agreed, I downloaded dotnet-runtime-5.0-5.0.4-1.fc34.x86_64.rpm and
> checked it too (although not the other subpackages in that build).
>
>>double-checked that dotnet5.0 is part of the scanned set.
>
> Great, thanks!

Agreed: thanks for looking into this!

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Rebuilding packages that use std::call_once from libstdc++

2021-03-30 Thread Omair Majid
Hi,

Jonathan Wakely  writes:

> Due to an unplanned ABI break that I caused in libstdc++, I will soon
> start to rebuild the packages listed below. This rebuild will remove
> references to some symbols in libstdc++.so which do not work as
> intended, and so will not be present in the final gcc-11.1.0 release.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
>
> Package maintainers should not need to do anything, but will see a
> %release bump and a rebuild.

>  dotnet3.1

I am bit surprised that dotnet3.1 is in that list but not dotnet5.0.

Is there some way I can confirm whether a package (like dotnet5.0) is
affected or not?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Mono help

2021-01-07 Thread Omair Majid

Jerry James  writes:

> The dll builds without any trouble.

Great!

> understand that after that I need to pack things up into a nupkg and
> install that under %{_libdir}/dotnet, right?

Kind of.

At this point, we don't have a well-defined location where nuget
packages should be installed within Fedora. So I don't know where it
should be installed.

%{_libdir}/dotnet is *not* the place for this, though. That's where .NET
itself is installed.

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Mono help

2021-01-07 Thread Omair Majid

Jerry James  writes:
> I'm building in mock, with the network off.  That's why I had to
> remove netstandard2.0 support, because it wanted to download stuff and
> failed due to the missing network.  But building against
> netstandard2.1 works without a network.

Oh, that's great news! I though it was all broken, but I am glad to hear
I was wrong.

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Mono help

2021-01-06 Thread Omair Majid
Hi,

I have some thoughts but no real answers, sorry.

Jerry James  writes:

> Antlr4 4.9.1 is out.  This is mostly a small change from version 4.9,
> except that the mono runtime has changed drastically.

That's a little brave for a patch release

Mono and .NET Core are two different implementations of .NET/C#.
Dropping support for one implementation and adding support for another
in a point release is going to lead to many surprises. There are major
functional and other differences between the two.

And it's even more so in an Linux distro context: dotnet is not part of
many Linux distributions at this point (aside from Fedora/RHEL/CentOS
plus others that ship binary packages without building them). So using
`dotnet build` is just not an option for, say, Debian or Ubuntu.

> Upstream now
> builds against netstandard2.0 and netstandard2.1, and I can no longer
> build with "xbuild Antlr4.mono.sln" because Antlr4.mono.sln is gone.
> I figured out that the package needs to BR: dotnet, and build with
> "dotnet build", and that we have to build against netstandard2.1 only.
> That works fine

Locally, maybe. Most likely, It won't work in koji: `dotnet build`
downloads nuget packages at build time. I expect this to break when
network is not available (which is the case in koji).

(You could argue that this is something that the .NET
upstream+downstream maintainers should fix and you wouldn't be entirely
wrong. This really cripples building any C# project within Fedora using
.NET Core.)

> , but then we try to install with gacutil:
>
> Failure adding assembly
> runtime/CSharp/bin/Debug/netstandard2.1/Antlr4.Runtime.Standard.dll to
> the cache: Strong name cannot be verified for delay-signed assembly
>
> Upstream provides Antlr4.snk, which is the public key.  They don't
> hand out their private key for obvious reasons, so I cannot sign with
> it.  So I remove the signing bits from Antlr4.csproj and try again:
>
> Failure adding assembly
> runtime/CSharp/bin/Debug/netstandard2.1/Antlr4.Runtime.Standard.dll to
> the cache: Attempt to install an assembly without a strong name

Here's the thing with modern .NET (including .NET Core 3.1 and the
recently released .NET 5): there's no Global Assembly Cache (GAC). Even
if you managed to install the `.dll` files into the cache, they wont be
used. .NET Core really wants you to use nuget packages (`.nupkg` files)
as the dependency mechanism. It's as if Java moved from managing
dependencies via `.class` files (similar to `.dll` files) to `.jar`
files (similar to `.nupkg` files).

I suggest you think about packaging up the `.nupkg` files and shipping
those in the RPM package (assuming you can get past the build-offline
issues).

As for strong name signing, some projects (such as .NET Core itself)
have a "open" snk file that they use for "public-signing":

https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Arcade.Sdk/tools/snk/Open.snk

Here's an example of how it's being used:

https://github.com/dotnet/arcade/blob/5bc6a0c39d9e8a89f4da5de53f1a2f9b3a6fe5db/src/Microsoft.DotNet.Arcade.Sdk/tools/StrongName.targets#L55-L67

> I don't understand Mono or .NET at all, really.  Can somebody who does
> tell me what I'm supposed to do?

I think you need to talk to upstream and tell them that this breaks
building Antlr4 for some prominent Linux distributions that don't allow
access to the nuget repository via the network (which `dotnet` uses by
default). This sounds like a big regression for a minor patch release.

Longer term, by moving to .NET Core, you should think about moving to
`nupkg` files instead of the GAC.

Regards,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Please untag dotnet3.1-3.1.106-1.fc33

2020-08-13 Thread Omair Majid

Jeff Law  writes:

> I can't help with the untagging, but I'm here if there's anything
> going wrong with the system tools that is ultimately affecting dotnet.

Thanks.

Just for context:

.NET Core uses a bundled (and modified) copy of libunwind for unwinding
the stack. This version doesn't work on aarch64 when built with one of
the new CFLAGS introduced in Fedora 33/34: -mbranch-protection=standard.

The upstream version of libunwind (the Fedora libunwind package) is also
broken (in a completely different way) for aarch64 from a .NET Core
point of view too.

For now, my "fix" is to remove `-mbranch-protection=standard` from
CFLAGS on aarch64 to get things working.

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Please untag dotnet3.1-3.1.106-1.fc33

2020-08-13 Thread Omair Majid
Hi,

One of the recent builds produced for "dotnet3.1" for rawhide is broken
on aarch64. It built successfully in koji, but produced aarch64 binaries
that segfault on startup. A new build of dotnet3.1 requires a working
older build. That means all recent builds of dotnet3.1 in Rawhide/F33 on
failed too.

As I understand it, the most recent (broken) build needs to be untagged.
Then a newer build can build using an older (working) build of
dotnet3.1.

This is the broken build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1544928

I tried it myself, but I don't seem to have permissions:

$ koji untag-build f33 dotnet3.1-3.1.106-1.fc33
2020-08-13 10:11:30,777 [ERROR] koji: ActionNotAllowed: tag requires autosign 
permission

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned dbus-java and libmatthew-java

2020-08-04 Thread Omair Majid
Hi,

I have just orphaned these two packages:

https://src.fedoraproject.org/rpms/dbus-java
https://src.fedoraproject.org/rpms/libmatthew-java

I have not been able to provide them with the care they deserve.

If you are interested in the packages, please pick them up. Here's some
additional information that you may find useful if you are interested in
maintaining these.

The original upstream for dbus-java and libmatthew-java is dead. The
last commit on dbus-java was 10 years ago [1]. libmatthew-java doesn't
even have a source repository [2].

dbus-java has a new fork now which is being maintained [3]. However, the
fork is not source or binary compatible with the original dbus-java. It
also uses a completely different build system. The fork doesn't use
libmatthew-java, but instead uses jnr-socket, among other maven
artifacts.

Switching to the fork would require the spec file to be mostly
re-written.

It probably makes sense to retire libmatthew-java and update dbus-java
to the (incompatible) new upstream version.

Omair

[1] https://github.com/freedesktop/dbus-java/
[2] http://www.matthew.ath.cx/projects/java/
[3] https://github.com/hypfvieh/dbus-java/

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Bundled compiler conundrum

2020-06-25 Thread Omair Majid

Michael Cronenworth  writes:

> The bi-weekly Wine update last week brought with it a minor version 
> (5.0.0->5.1.0)
> wine-mono update. The update itself is not minor. The tarball is now bundling 
> a
> Clang LLVM-based MinGW toolchain in binary form that is also required to 
> compile the
> package. My first effort at stripping it out to use our Fedora MinGW toolchain
> doesn't work with the Clang style CFLAGS they have switched to. Before I 
> spend more
> time de-bundling:
>
> I know bundled libraries are allowed, but what about bundled compilers?

If I am readying your question correctly, it's not just that wine
bundles compilers and libraries, it's that wine bundles pre-built
binaries of compilers and libraries.

As I understand it, bundling and use of pre-built binaries are two
different issues.

Bundling is allowed.

My reading of the packaging guidelines says using pre-bulit binaries is
not allowed at all:

"""
When you encounter prebuilt binaries in a package you MUST:

 -  Remove all pre-built program binaries and program libraries in %prep
prior to the building of the package. Examples include, but are not
limited to, *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc,
*.pyo, *.egg, *.so, *.swf files.
"""

And

"""
Some software (usually related to compilers or cross-compiler
environments) cannot be built without the use of a previous toolchain or
development environment (open source). If you have a package which meets
this criteria, contact the Fedora Packaging Committee for approval.
Please note that this exception, if granted, is limited to only the
initial build of the package. You may bootstrap this build with a
"bootstrap" pre-built binary, but after this is complete, you must
immediately increment Release, drop the "bootstrap" pre-built binary,
and build completely from source. Bootstrapped packages containing
pre-built "bootstrap" binaries must not be pushed as release packages or
updates under any circumstances.
"""

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Re-Launching the Java SIG

2020-05-12 Thread Omair Majid
Hi,

A bit of a tangential question:

Zbigniew Jędrzejewski-Szmek  writes:

> So maybe just nuke the outdated parts (member lists, "state of affairs"
> content), and keep the rest?

My wiki-foo sucks. Is there some way to automatically generate a list of
members on the wiki from a FAS group?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The Chromium Dilemma

2020-04-14 Thread Omair Majid

Florian Weimer  writes:

> * Omair Majid:
>
>> Florian Weimer  writes:
>>
>>> * Jan Kratochvil:
>>>
>>>> gold is also limited by 'ulimit -S -n', I had to raise it while building 
>>>> LLDB
>>>> (using -DLLVM_USE_LINKER=gold).
>>>
>>> gold should either do this upon start (like OpenJDK does),
>>
>> Do you have any pointers to source or docs that explain the OpenJDK
>> technique for this?
>
> Uhm, now I have to look.  I hope it really does that, I noticed it only
> because it was possible to open more than 1024 files, contrary to what I
> expected based on the system configuration.
>
> The responsible code is os::init_2(), in
> src/hotspot/os/linux/os_linux.cpp:
>
>   if (MaxFDLimit) {
> // set the number of file descriptors to max. print out error
> // if getrlimit/setrlimit fails but continue regardless.
> struct rlimit nbr_files;
> int status = getrlimit(RLIMIT_NOFILE, &nbr_files);
> if (status != 0) {
>   log_info(os)("os::init_2 getrlimit failed: %s", os::strerror(errno));
> } else {
>   nbr_files.rlim_cur = nbr_files.rlim_max;
>   status = setrlimit(RLIMIT_NOFILE, &nbr_files);
>   if (status != 0) {
> log_info(os)("os::init_2 setrlimit failed: %s", os::strerror(errno));
>   }
> }
>   }
>
> rlim_max is what is sometimes called the hard limit, rlim_cur the soft
> limit.  It is the difference between “ulimit -S -n” and “ulimit -H -n”.
> The quoted code fragment raises the soft limit up to the hard limit,
> which is as far as you can go without additional privileges.
>
> Does this answer your question?

Yes, it does. Thanks.

(I was secretly hoping there was a way to bump rlim_cur past
the current value of rlim_max...)

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The Chromium Dilemma

2020-04-14 Thread Omair Majid
Hi,

Florian Weimer  writes:

> * Jan Kratochvil:
>
>> gold is also limited by 'ulimit -S -n', I had to raise it while building LLDB
>> (using -DLLVM_USE_LINKER=gold).
>
> gold should either do this upon start (like OpenJDK does),

Do you have any pointers to source or docs that explain the OpenJDK
technique for this?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned mongo-java-driver

2020-02-17 Thread Omair Majid
Hi,

I have just orphaned the mongo-java-driver package.

I have not been able to give it the time or attention it needs.
Hopefully someone else can take over this package.

Omair
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned appframework

2020-02-13 Thread Omair Majid
Hi,

I have just orphaned appframework:

https://src.fedoraproject.org/rpms/appframework

This package was failing to build in rawhide because one of its
dependencies, swing-layout was orphaned and removed. Unfortunately, I
don't have the time or interest to take over and maintain swing-layout.

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned bindex

2020-02-11 Thread Omair Majid
Hi,

Starting with Fedora 32, bindex can not be built anymore:

https://koji.fedoraproject.org/koji/taskinfo?taskID=41316281

This is because one of its dependencies, felix-osgi-core, has been
orphaned/retired:

https://src.fedoraproject.org/rpms/felix-osgi-core/tree/master

I no longer use bindex, so I have no interest in taking up and
maintaining felix-osgi-core in addition to bindex.

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned ini4j

2020-02-03 Thread Omair Majid
Hi,

Starting with Fedora 32, ini4j can not be built anymore:

https://kojipkgs.fedoraproject.org//work/tasks/751/41340751/root.log

This is because one of its dependencies, xmlrpc, has been
orphaned/retired:

https://src.fedoraproject.org/rpms/xmlrpc

I no longer use ini4j, so I have no interest in taking up and
maintaining xmlrpc in addition to ini4j.

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaning swingx

2020-01-02 Thread Omair Majid
Hi,

Due to the lack of time I have orhpaned swingx.

If anyone wants to maintain it, please go ahead and pick it up. Please
note that upstream is dead. swingx (and the rest of swinglabs projects)
were lost as part of the dev.java.net shutdown years ago [1]. The last
release of swingx on maven central was in 2010, 10 years ago [2].

[1] 
https://stackoverflow.com/questions/6818528/what-is-the-status-of-swinglabs-swingx-post-acquisition
[2] https://mvnrepository.com/artifact/org.swinglabs/swingx

Regards,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

2019-10-30 Thread Omair Majid
Hi,

Ben Cotton  writes:

> The annobin package provides two components, a plugin for gcc that
> records details about how a program was compiled and an analyser that
> uses this information to produce a report on the security hardening
> status of the compiled program.  Currently the plugin is being used as
> part of the build process for Fedora packages (when they are built
> using gcc), but the analysing program is not being run.  This proposal
> is to have the analyser (called annocheck) run when creating
> information for review by the Bodhi update process, possibly allowing
> an update to be delayed until the security issues are addressed.

I currently run annocheck manually on my builds, so I am a fan of this
change.

But I think it's worth calling out one limitation: this currently mostly
works with gcc. clang is a bit behind in implementing some of the
features that annocheck looks at. With Fedora 30, annocheck would
cleanly skip most of clang-produced binaries. With Fedora 31, clang
seems to insert some of the meta-data that annocheck looks for, but
doesn't quite implement to match the gcc standard. I have recently run
into failures flagged by annocheck that I need to dig into on Fedora 31.

> It is desirable that the packaging guidelines be updated to describe
> the security hardening features examined by annocheck.  (If they are
> not already mentioned in the guidelines).

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
has some of this, but not all. It seems to me like annocheck is more
strict than the current packaging guidelines.

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: epel-8-{x86_64,ppc64le,aarch64} chroots enabled in copr

2019-09-25 Thread Omair Majid
Hi,

Pavel Raiskup  writes:

> CentOS 8 repositories are now available, so @msuchy released new
> `mock-core-configs` (see updates-testing), and so we were allowed to enable
> epel-8 chroots in Copr!  Feel free to build against them.

First, of all, thanks! This is great new!

I wanted to try this out. I tried building a package in copr against
epel-8 and it seems to be missing some packages.

This is the EPEL 8 build:
https://copr-be.cloud.fedoraproject.org/results/@dotnet-sig/dotnet-preview/epel-8-x86_64/01040196-dotnet3.0/

root.log.gz says: No matching package to install: 'lttng-ust-devel'

But I know lttng-ust-devel exists in RHEL 8. It was also built by CentOS
8 here: https://koji.mbox.centos.org/koji/buildinfo?buildID=1299

Am I doing something wrong?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Better interactivity in low-memory situations

2019-08-09 Thread Omair Majid

Hi,

Chris Murphy  writes:

> Certain workloads, such as building webkitGTK from source, results in
> heavy swap usage eventually leading to the system becoming totally
> unresponsive. Look into switching from disk based swap, to swap on a
> ZRAM device.

It sounds like the same issue that has been in the news recently:

- https://www.phoronix.com/scan.php?page=news_item&px=Linux-Does-Bad-Low-RAM
- https://news.ycombinator.com/item?id=20620545

Older sources with more information:

- https://lwn.net/Articles/759658/
- 
https://superuser.com/questions/1115983/prevent-system-freeze-unresponsiveness-due-to-swapping-run-away-memory-usage

(I learned about this bug the hard way; my machine experienced this bug
in the middle of a public presentation a few years ago.)

Regards,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [HEADS UP] Rawhide buildroot now has glibc-minimal-langpack instead

2018-12-06 Thread Omair Majid
* Petr Pisar  [2018-12-03 11:24]:
> On 2018-11-28, Igor Gnatenko  wrote:
> > the removal of glibc-all-langpacks from the buildroot[0] is done.
> > Standard buildroot has decreased from 445 to 237 megabytes in
> > installed size ;)
> >
> That's nice, but Koji builders have not been reconfigured away from
> LANG=en_US.UTF-8 and that means that all builds run in C (not C.UTF-8)
> locale now and e.g. every Perl package build spits a warning like this:
> 
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LANG = "en_US.UTF-8"
> are supported and installed on your system.
> 
> Example
> .

This is even causing some of my builds to fail because some cmake
variables (CMAKE_SYSTEM_PROCESSOR below) end up containing a warning:

  -- Found assembler: /usr/bin/clang
  CMAKE_SYSTEM_PROCESSOR: _bin_sh: warning: setlocale: LC_ALL: cannot 
change locale (en_US.UTF-8)
  x86_64
  CMake Error at functions.cmake:7 (message):
Only AMD64, ARM64 and ARM are supported
  Call Stack (most recent call first):
CMakeLists.txt:175 (clr_unknown_arch)

What's the correct way to disable this "setlocale: LC_ALL: cannot change
locale (en_US.UTF-8)" warning? What environment variables should I be
(un)setting when building in koji? Or should I install a langpack
instead?

Thanks,
Omair

-- 
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

2018-08-22 Thread Omair Majid
* Ben Cotton  [2018-08-22 16:38]:
> 9420 source packages (43% of the total count) come closer to
> compliance with Fedora's packaging guidelines.  The Group: tag has
> been in a "should not use" state since March of 2017.

Can rpmlint be patched to warn about using the 'Group:' tag?

Omair

-- 
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MIO2QYB45WML6NED7GLMQ5UDROFPF57V/


Re: Mono - Do we have a maintainer?

2018-08-22 Thread Omair Majid
* Dan Horák  [2018-08-22 03:55]:
> a nice thing on Mono is that it is fully multi-arch, supporting all
> Fedora arches. Won't be multi-arch problem for msbuild or .NET Core?

Oh. Right, that would be a problem. .NET Core upstream essentially
supports x86_64 only. arm-hfp, aarch64 and x86 are supported to some
extent. Every other platform is pretty much unsupported.

Thanks,
Omair

-- 
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KEAXTLKC52CL7AX6L6Y6XUBW65GO6HDD/


Re: Mono - Do we have a maintainer?

2018-08-20 Thread Omair Majid
* Michael Cronenworth  [2018-08-15 10:19]:
> On 08/15/2018 08:55 AM, Florian Weimer wrote:
> > Are you sure about that?  Ocaml does it as well.
> 
> The guidelines allow an initial bootstrap from binaries, but subsequent
> builds are supposed to build from source. The problem is that we can't build
> without the binaries at all. The Roslyn compiler requires the "msbuild"
> tool, which hasn't been successfully built from source.
> 
> I don't have the time to lend, but if others are willing to step in that 
> would be great.

It's possible to build msbuild (and .NET Core) from source here:
https://github.com/dotnet/source-build/

But then there's the recursive problem of building all those binary
(nuget) packages that source-build needs, from source.

We are working on trying to improve .NET Core (including msbuild) and
bring it to a point where it can be added to Fedora proper, but it's a
fairly long term goal.

Omair

-- 
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/35JKDUW64NORTWV4YTIH4WOMOLI34IEA/


Orphaned jemmy

2018-03-15 Thread Omair Majid
I no longer have the time/resources/interest to maintain jemmy:
https://src.fedoraproject.org/rpms/jemmy/

I have orphaned it. If anyone wants to take over maintainership, please
do so.

Thanks,
Omair

-- 
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: ERROR: No build ID note found in

2017-04-13 Thread Omair Majid
* Richard W.M. Jones  [2017-04-13 12:01]:
> So is there a way to get find-debuginfo.sh to tolerate these files?
> (A cursory look at find-debuginfo.sh doesn't show anything obvious,
> but I could be missing something).  Or maybe there's another way to
> solve this?

For a hacky workaround, does find-debuginfo.sh stop complaining if you
remove the executable flag from the object files?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Orphaning freemarker

2017-03-24 Thread Omair Majid
Hi,

I am no longer able to devote any time to maintain freemarker. I am
orphaning it.

I believe it is a dependency for the following packages.
bval-0:1.1.1-3.fc26.src
bval-json-0:1.1.1-3.fc26.noarch
cookcc-0:0.3.3-15.fc26.noarch
cookcc-0:0.3.3-15.fc26.src
eclipse-cdt-1:9.2.0-4.fc26.src
eclipse-cdt-1:9.2.0-4.fc26.x86_64
eclipse-cdt-qt-1:9.2.0-4.fc26.x86_64
fmpp-0:0.9.14-7.fc26.noarch
fmpp-0:0.9.14-7.fc26.src
jersey-0:2.23.2-2.fc26.noarch
jersey-0:2.23.2-2.fc26.src
jersey1-0:1.19-9.fc26.src
jersey1-contribs-0:1.19-9.fc26.noarch
restlet-jse-0:2.3.1-5.fc26.noarch
restlet-jse-0:2.3.1-5.fc26.src
sbinary-0:0.4.2-6.fc26.src
spring-ldap-0:1.3.1-15.fc26.noarch
spring-ldap-0:1.3.1-15.fc26.src
springframework-0:3.2.18-2.fc26.src
tiles-0:2.2.2-16.fc26.noarch
tiles-0:2.2.2-16.fc26.src
undertow-js-0:1.0.2-2.fc26.src

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: [fedora-java] Re: java-1.8.0-openjdk i686 1:1.8.0.102-2.b14.fc26 is broken ... ?

2016-09-16 Thread Omair Majid
Hi,

* Omair Majid  [2016-09-16 11:59]:
> * gil  [2016-09-16 02:27]:
> > The system is out of resources.
> > Consult the following stack trace for details.
> > java.lang.StackOverflowError
> > at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3250)
> > at 
> > com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897)
> > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:576)
> > at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1825)
> 
> Does increasing the thread stack size help? Something like
> 
> MAVEN_OPTS=-Xss1024k

Works for me with this change to the spec file:

-export MAVEN_OPTS="-Xms1024m -Xmx3096m -XX:PermSize=128m 
-XX:MaxPermSize=384m"
+export MAVEN_OPTS="-Xms1024m -Xmx2048m -Xss5m"

Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=15662528

root.log shows:

> DEBUG util.py:421:   java-1.8.0-openjdk i686 
> 1:1.8.0.102-2.b14.fc26   build 233 k
> DEBUG util.py:421:   java-1.8.0-openjdk-devel   i686 
> 1:1.8.0.102-2.b14.fc26   build 9.8 M
> DEBUG util.py:421:   java-1.8.0-openjdk-headlessi686 
> 1:1.8.0.102-2.b14.fc26   build  31 M

Cheers,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: [fedora-java] java-1.8.0-openjdk i686 1:1.8.0.102-2.b14.fc26 is broken ... ?

2016-09-16 Thread Omair Majid
Hi,

* gil  [2016-09-16 02:27]:
> The system is out of resources.
> Consult the following stack trace for details.
> java.lang.StackOverflowError
>   at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3250)
>   at 
> com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897)
>   at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:576)
>   at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1825)

Does increasing the thread stack size help? Something like

MAVEN_OPTS=-Xss1024k

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Removing packages that have broken dependencies in F23 tree, v2

2015-10-05 Thread Omair Majid
* Kalev Lember  [2015-10-05 09:02]:
> Here's another look at F23 broken dependencies.
>
> Based on today's Branched report [1], the following packages have
> remaining broken dependencies (package maintainers BCC'd to this email):
> 
>Package(co)maintainers
> 
> netbeans-platform moceap, dbhole, omajid

The list of maintainers doesn't look right. I have no commit access to
this package for F23 (or Rawhide) [1]. I am being BCC'ed when I can't do
anything :(

Thanks,
Omair

[1] https://admin.fedoraproject.org/pkgdb/package/netbeans-platform/

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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 netbeans related packages

2015-03-31 Thread Omair Majid
Hi,

I am no longer interested in maintaining netbeans-related packages:

- netbeans-javaparser
- netbeans-platform
- netbeans-resolver
- netbeans-svnclientadapter

I am going to orphan them.

Regards,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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: Spins-kickstarts change for OpenJDK 8

2014-06-25 Thread Omair Majid
* Bruno Wolff III  [2014-06-24 15:40]:
> On Tue, Jun 24, 2014 at 15:13:01 -0400,
>  Omair Majid  wrote:
> >Hi,
> >
> >* Omair Majid  [2014-06-24 14:31]:
> >>With the Java 8 Change [0] that promotes java-1.8.0-openjdk to the
> >>default Java runtime, I am going to be retiring java-1.7.0-openjdk
> >>shortly.
> >
> >And this patch, for spins-kickstarts, removes all mention of
> >java-1.7.0-openjdk from the kickstart files.
> 
> We'll want to wait until after it is blocked to remove those references.
> Note those were keeping java-1.7.0 out of spins, and we'll want to keep
> doing that until it is gone.

java-1.7.0-openjdk is now blocked from f21. But I can't push the
spins-kickstart change:

$ git push
Counting objects: 23, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 409 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
error: insufficient permission for adding an object to repository
database ./objects

fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://git.fedorahosted.org/git/spin-kickstarts.git
 ! [remote rejected] master -> master (n/a (unpacker error))
 error: failed to push some refs to
 'ssh://git.fedorahosted.org/git/spin-kickstarts.git'

Do I need commit access? Can someone else please push this for me?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Spins-kickstarts change for OpenJDK 8

2014-06-24 Thread Omair Majid
Hi,

* Omair Majid  [2014-06-24 14:31]:
> With the Java 8 Change [0] that promotes java-1.8.0-openjdk to the
> default Java runtime, I am going to be retiring java-1.7.0-openjdk
> shortly.

And this patch, for spins-kickstarts, removes all mention of
java-1.7.0-openjdk from the kickstart files.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
diff --git a/fedora-livecd-desktop.ks b/fedora-livecd-desktop.ks
index 8fe9449..2215714 100644
--- a/fedora-livecd-desktop.ks
+++ b/fedora-livecd-desktop.ks
@@ -25,7 +25,6 @@
 
 # Drop the Java plugin
 -icedtea-web
--java-1.7.0-openjdk
 -java-1.8.0-openjdk
 
 # Drop things that pull in perl
diff --git a/fedora-livecd-mate-compiz.ks b/fedora-livecd-mate-compiz.ks
index c3166c7..6dee447 100644
--- a/fedora-livecd-mate-compiz.ks
+++ b/fedora-livecd-mate-compiz.ks
@@ -38,7 +38,6 @@ midori
 
 # Drop the Java plugin
 -icedtea-web
--java-1.7.0-openjdk
 -java-1.8.0-openjdk
 
 # Drop things that pull in perl
-- 
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: Comps change for OpenJDK 8

2014-06-24 Thread Omair Majid
* Aleksandar Kurtakov  [2014-06-24 14:36]:
> In the commit I see java-1.5.0-gcj, you might want to drop it now that 
> gcc-java is no longer built. 

Done. This was accidentally overlooked when java-1.5.0-gcj was retired.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Comps change for OpenJDK 8

2014-06-24 Thread Omair Majid
Hi,

With the Java 8 Change [0] that promotes java-1.8.0-openjdk to the
default Java runtime, I am going to be retiring java-1.7.0-openjdk
shortly.

I need to make a change to comps to make sure that it does not try and
pull in java-1.7.0-openjdk. Patch is attached. It was reviewed on IRC by
Dennis Gilmore (thanks!), but I am posting it here for wider feedback.
Unless I hear any objections, I am going to push this shortly.

Cheers,
Omair

[0] https://fedoraproject.org/wiki/Changes/Java8

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
diff --git a/comps-f21.xml.in b/comps-f21.xml.in
index 81a9847..dfcba47 100644
--- a/comps-f21.xml.in
+++ b/comps-f21.xml.in
@@ -812,8 +812,8 @@
 false
 
   abrt-java-connector
-  java-1.7.0-openjdk
-  java-1.7.0-openjdk-devel
+  java-1.8.0-openjdk
+  java-1.8.0-openjdk-devel
   jboss-as
   jboss-modules
   maven
@@ -3828,7 +3828,7 @@
 false
 false
 
-  java-1.7.0-openjdk
+  java-1.8.0-openjdk
   abrt-java-connector
   icedtea-web
   java-1.5.0-gcj
@@ -3844,7 +3844,7 @@
 
   ant
   ecj
-  java-1.7.0-openjdk-devel
+  java-1.8.0-openjdk-devel
   abrt-java-connector
   ant-antlr
   ant-apache-bcel
@@ -3884,9 +3884,9 @@
   gnu-getopt
   jakarta-oro
   jakarta-taglibs-standard
-  java-1.7.0-openjdk-demo
-  java-1.7.0-openjdk-javadoc
-  java-1.7.0-openjdk-src
+  java-1.8.0-openjdk-demo
+  java-1.8.0-openjdk-javadoc
+  java-1.8.0-openjdk-src
   javamail
   java_cup
   jdepend
-- 
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 System Wide Change: Fedora 21 Make 4.0 Update

2014-06-12 Thread Omair Majid
* Peter Robinson  [2014-06-12 04:25]:
> On Thu, Jun 12, 2014 at 12:50 AM, Omair Majid  wrote:
> > * Jaroslav Reznik  [2014-04-14 08:32]:
> >> = Proposed System Wide Change: Fedora 21 Make 4.0 Update =
> >> https://fedoraproject.org/wiki/Changes/F21Make40
> >
> >> == Detailed Description ==
> >> The purpose of this update is to synchronize Fedora with the most recent 
> >> Make
> >> release.
> >
> > The contingency for this was supposed to trigger at the Mass Rebuild.
> > However, koji tells me that the first time Make 4.0 was built in rawhide
> > was during the Mass Rebuild [1] :(
> >
> > And of course, some of the changes in Make broke other programs. OpenJDK
> > 8, for example, currently fails to build because of this. It built for
> > the mass rebuild (because make was not built until that point) but fails
> > now.
> >
> > What's the plan here?
> 
> What fix do you propose for the Openjdk8 side of the problem?

Turns out, OpenJDK 8 was rely on some weird edge case. I haven't looked
into it yet, but there's a one-liner fix someone pointed me to [1], so
OpenJDK 8 should be easy to fix. I am just surprised that a major change
went in at such a surprising time (middle of mass rebuild).

Thanks,
Omair

[1] http://icedtea.classpath.org/hg/icedtea8-forest/hotspot/rev/b4ea3a87f707

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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

2014-06-11 Thread Omair Majid
* Adam Jackson  [2014-06-09 12:01]:
> In the xorg-x11-docs case it's explicitly BuildRequires:
> java-1.7.0-openjdk;

Okay. Please don't do that. Use java-devel. Otherwise, this will break
on future updates to Java 8, 9 an later ones.

> changing it to plain java-devel actually fixes the
> build, presumably because either 1.7.0 no longer provides that or yum
> just decides it likes 1.8.0 better.

java-1.8.0-openjdk provides the highest-versioned 'java-devel' (1:1.8.0,
compared with java-1.7.0's 1:1.7.0).

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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

2014-06-11 Thread Omair Majid
* Peter Robinson  [2014-06-09 11:35]:
> That's likely because both OpenJDK7 and OpenJDK8 both provide
> java-devel (based on a the repo as it stood at yesterday's compose so
> it doesn't include the mass rebuild packages):
> 
> # repoquery --whatprovides java-devel
> java-1.7.0-openjdk-devel-1:1.7.0.60-2.5.0.22.pre04.fc21.x86_64
> java-1.8.0-openjdk-devel-1:1.8.0.5-9.b13.fc21.x86_64
> 
> I'm sure it should likely only be provided by one or the other.

No. JPackage/Fedora guidelines require all Java implementations to
provide 'java-devel = version-of-java-implementation'.

In practice, that means that all Java packages should require
java-devel. The problem is the bytecode level. The Java compiler by
default produces bytecode that is only compatible with itself or a
higher version of Java. Older Java implementations error out when they
see it. This is kind of opposite of what we want as a distribution,
where all java bytecode should correspond with the lowest version of
Java implementation that we ship.

Anyway, this whole point should become moot. java-1.7.0-openjdk will be
deprecated and removed from the distribution before Change Freeze. Only
java-1.8.0-openjdk will be left.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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 System Wide Change: Fedora 21 Make 4.0 Update

2014-06-11 Thread Omair Majid
* Jaroslav Reznik  [2014-04-14 08:32]:
> = Proposed System Wide Change: Fedora 21 Make 4.0 Update = 
> https://fedoraproject.org/wiki/Changes/F21Make40

> == Detailed Description ==
> The purpose of this update is to synchronize Fedora with the most recent Make 
> release.

The contingency for this was supposed to trigger at the Mass Rebuild.
However, koji tells me that the first time Make 4.0 was built in rawhide
was during the Mass Rebuild [1] :(

And of course, some of the changes in Make broke other programs. OpenJDK
8, for example, currently fails to build because of this. It built for
the mass rebuild (because make was not built until that point) but fails
now.

What's the plan here?

Thanks,
Omair

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=525899

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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 System Wide Change: Java 8

2014-03-27 Thread Omair Majid
Hi,

* Stephen John Smoogen  [2014-03-26 11:55]:
> I would say that there needs to be something a bit larger than a
> rebuild but a mass test so that you end up with finding out that someone's 
> hack
> to make java-7 do something neat isn't java-8 runtime saying 'crash'.

What about holding a Test Day [1] for this? Do you have anything else in
mind?

Thanks,
Omair

[1] https://fedoraproject.org/wiki/QA/Test_Days

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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 System Wide Change: Java 8

2014-03-25 Thread Omair Majid
* Mikolaj Izdebski  [2014-03-24 11:55]:
> That's exactly the problem.  We need to use a modified version of
> java-1.8.0-openjdk with extra provides and adjusted priorities for
> alternatives.

I have started a new java-1.8.0-openjdk build that should fix this:
http://koji.fedoraproject.org/koji/buildinfo?buildID=506921

>   Blocking java-1.7.0-oepnjdk may also be required.  This
> makes it impossible to scratch-build Java packages using f21-build
> target in current state.

Is there anything I can/should do here? Shall I file a rel-eng ticket to
block java-1.7.0-openjdk? Would it be worth waiting a little while to
ensure that there are no show-stopper bugs in java-1.8.0-openjdk?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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 System Wide Change: Java 8

2014-03-25 Thread Omair Majid
* Mikolaj Izdebski  [2014-03-24 11:41]:
> On 03/22/2014 06:15 AM, Miloslav Trmač wrote:
> > Given the known large number of failures (OptionalJavadocs says "80% build
> > failure rate" without saying that all are JavaDoc-related), we really
> > should do a mass rebuild to identify which packages fail to build *and* to
> > file bugs soonish, instead of waiting for a Fedora-wide mass rebuild and
> > then scrambling to fix dozens/hundreds of build failures in to avoid
> > slipping the schedule.  We don't necessarily need an official one, perhaps
> > only in a never-to-be-merged side tag (or even scratch builds?)
> 
> Agreed.

Should I update the proposal to clarify that a mass rebuild is required,
then?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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 System Wide Change: Java 8

2014-03-21 Thread Omair Majid


- Original Message -
From: "Dan Horák" 
> Jaroslav Reznik  wrote:
> > Make Java 8 (provided by OpenJDK 8 which is java-1.8.0-openjdk) the
> > default Java runtime. The current default Java runtime (Java 7,
> > provided by OpenJDK 7, java-1.7.0-openjdk) will be obsoleted and
> > removed.

> are we confident OpenJDK 8 works well on all Fedora arches, not only on
> the primary ones?

Theoretically, yes. If OpenJDK 7 supports an architecture, OpenJDK 8 should 
support it about as well (if not better). We may need tweaks and patches to 
make sure OpenJDK 8 builds correctly everywhere, but that's one of the things 
we can fix in rawhide in the coming weeks.

If you can get me access to machines, I can try building OpenJDK 8 there myself.

Thanks,
Omair

-- 
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 System Wide Change: Java 8

2014-03-21 Thread Omair Majid


- Original Message -
> Is there an easy way to do test builds against 8 now?

java-1.8.0-openjdk is available in F19 (updates-testing), F20 (updates-testing) 
and in rawhide.

It doesn't provide 'java-devel' (which is what yum uses to find JDKs), so Koji 
shouldn't use java-1.8.0-openjdk as a dependency. But you can use 
java-1.8.0-openjdk-devel directly for local or scratch builds.

Thanks,
Omair
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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 System Wide Change: Optional Javadocs

2014-03-18 Thread Omair Majid
* Jaroslav Reznik  [2014-03-18 10:38]:
> Initial testing showed 80% build failure rate due to OpenJDK 8 
> update.

This is caused by a change in the default doclint settings used by
OpenJDK 8. Think '-Wall -Werror' for those more familiar with gcc.

We can patch OpenJDK 8 in Fedora to change the default to be more
lenient. This would be a deviation from upstream (and people might be
surprised when proprietary builds of Java exhibit different behaviour).

If this is the main/driving motivation behind this Change (and not slow
ARM boxes) please consider that fixing OpenJDK 8 is an option.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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 System Wide Change: System-wide crypto policy

2014-02-28 Thread Omair Majid
* Jaroslav Reznik  [2014-02-27 11:25]:
> = Proposed System Wide Change: System-wide crypto policy =
> https://fedoraproject.org/wiki/Changes/CryptoPolicy
> 
> An idea of how this will be implemented is to have each Fedora
> application's configuration file or compilation option will set a
> system default option. That is for example for applications that use
> GnuTLS or OpenSSL a priority string or cipher named "SYSTEM".  Then
> the shipped library will make sure that once the "SYSTEM" option is
> encountered the preconfigured system settings will be applied.
 
> == Scope ==
> There are changes required in GnuTLS, OpenSSL and NSS libraries. On a second 
> phase non-SSL crypto libraries could use these settings.

What about applications that do not use GnuTLS, OpenSSL and NSS? I
believe both OpenJDK and Bouncy Castle fall under this category.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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: UTF-8 locale in RPM build

2013-08-26 Thread Omair Majid
Hi Ian,

On 08/25/2013 04:17 PM, Ian Pilcher wrote:
> I'm trying to build a jpackage SRPM (jena-iri) on Fedora 19, and it's
> failing, because the locale (LANG) is apparently set to "C" during the
> build.  (javac and javadoc don't like non-ASCII characters in source
> files in an ASCII locale.)
> 
> What's the best way to set it to a UTF-8?  (Should I just add "export
> LANG=en_US.UTF-8" to the relevant sections of the SPEC file?)

I see that Mattias Ellert has already suggested fixing the encoding
being used by the java compiler to match the encoding used in actual
files. I just wanted to chime in and point out that there is a list of
common problems (and fixes) that you may run into when rebuilding older
packages against newer Java versions:

https://fedoraproject.org/wiki/Java7_Package_Rebuild_Status#Issues_descriptions_and_how_to_fix_them

Feel free to drop by #fedora-java if you run into more of these problems.

Cheers,
Omair
-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
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: packaging java unix sockets library

2013-06-19 Thread Omair Majid
On 06/19/2013 03:53 AM, Jiri Moskovcak wrote:
> I recently run into situation where I need to use unix socket in java
> program. Fro obvious reasons JAVA doesn't support it out of the box, so
> I have to use 3rd party library. After some googling I came to
> conclusion that there is no such library in Fedora which is quite a
> surprise for me (noone has ever needed unix socket in Java or is
> everyone bundling it??).

Fedora already contains libmatthew-java [1], which provides the ability
to read/write to unix sockets. I am not sure about documentation, but
dbus-java uses it, so at least there's some examples you can look at.
Unfortunately, upstream seems quite dormant now.

Cheers,
Omair

[1] http://www.matthew.ath.cx/projects/java/

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F19 DVD over size - what to drop?

2013-05-02 Thread Omair Majid
On 05/01/2013 04:21 PM, Bill Nottingham wrote:
> 
> I've dropped
> java-1.8.0-openjdk in the kickstart already, but that won't be enough.

As a maintainer of java-1.8.0-openjdk, I am sad to see it get dropped,
but given the circumstances, this makes sense. It's a preview after all.

> Here's everything new in the F19 DVD, sorted by size.
> http://paste.fedoraproject.org/9849/36743327/

Would a list of "source" package (ie, size of all binary package
produced by a single source package) work better since we can examine
bigger chunks at a time?

Could we also get a list of all packages on the DVD sorted by size?
Applying Amdahl's law will be more effective with more bigger packages.

Cheers,
Omair

[1] http://en.wikipedia.org/wiki/Amdahl's_law
-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: R

2012-10-22 Thread Omair Majid
On 10/22/2012 09:39 PM, Richard Vickery wrote:
> checking Java support in R... present:
> interpreter : '/bin/java'
> archiver: '/bin/jar'
> compiler: '/bin/javac'
> header prep.: '/bin/javah'
> cpp flags   : '-I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/../include 
> -I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/../include/linux'
> java libs   : '-L/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/lib/i386 
> -L/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/lib/i386/client -ljvm'
> checking whether JNI programs can be compiled... 
> configure: error: Cannot compile a simple JNI program. See config.log for 
> details.
> 
> Make sure you have Java Development Kit installed and correctly registered in 
> R.
> If in doubt, re-run "R CMD javareconf" as root.

Have you installed java-1.7.0-openjdk-devel?

Could you share the java/jni program that it's attempting to compile and
the command it uses for compilation, please?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packages in need of new maintainers

2012-10-03 Thread Omair Majid
On 10/03/2012 02:58 PM, Jon Ciesla wrote:
> On Wed, Oct 3, 2012 at 1:54 PM, Matthew Miller  
> wrote:
>> On Wed, Oct 03, 2012 at 01:23:02PM -0500, Jon Ciesla wrote:
>>> qemu -- QEMU is a FAST! processor emulator
>>
>> Hmmm. The virtmaint team is the owner of QEMU in the Fedora devel/18/17/16
>> collections, and lkundrak is the owner in EPEL 6. But do we even _have_ that
>> in EPEL 6?
> 
> I see no builds, and lots of qemu RPMS in RHEL.  Maybe I should retire
> the branch?
> 

This is also true for java-1.6.0-openjdk. It's in RHEL. I am not sure
why it's in EPEL too (ancient history, I guess).

Thanks,
Omair

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing needed (mongodb)

2012-01-17 Thread Omair Majid

On 01/17/2012 02:23 PM, Nathaniel McCallum wrote:

Good catch! However, I'm not sure what the best way to fix this is. Any
SELinux folk care to comment?


FWIW: 
https://github.com/mongodb/mongo/commit/8521b85b0e4447db8c5da6f0db249901608cc874


So leaving it as it is may not be too bad. But I would expect granting 
read access to the file should be safe here.


/me is not an selinux guy

Cheers,
Omair
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning netbeans

2012-01-11 Thread Omair Majid

Hi all,

I am the current maintainer of netbeans in fedora. Unfortunately, I have 
not been able to devote sufficient time to it to keep it in good shape. 
I am going to orphan it. If you are interested in it, please grab it.


I am still the owner of netbeans-platform (which is a a build dependency 
for netbeans), but co-maintainers for netbeans-platform are welcome too.


Thanks,
Omair
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why introducing hidden directories in /etc

2011-12-06 Thread Omair Majid
On 12/05/2011 05:26 PM, Kevin Fenzi wrote:
> Well, this happens... one thing that would be nice is if folks gave the
> rkhunter maintainers (of which I am one) a heads up so we could add it
> to the whitelist.
>

Apologies. I assumed (incorrectly it turns out) that rkhunter folks were 
aware of this. Google shows thousands of results for:
rkhunter "hidden directory found" "etc/java" [1]

Some of them include other distributions noting [2] and whitelisting 
/etc/.java/ [3] specifically.

> Otherwise we are just reacting when users see it.
>
> In any case, will try and get this updated soon...
>

Thanks, much appreciated!

Cheers,
Omair

[1] 
https://www.google.com/search?q=rkhunter+"hidden+directory+found"+"etc/java";
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626218
[3] https://bugs.mageia.org/show_bug.cgi?id=883
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why introducing hidden directories in /etc

2011-12-05 Thread Omair Majid
Hi,

On 12/03/2011 07:02 AM, Reindl Harald wrote:
> why are permanently with updates introduced new hidden folders
> in /etc which let alerting "rkhunter"? openjdk is only a recent
> example, but happended often in the last years with several packages
>
> [harry@srv-rhsoft:~]$ ls -lha /etc/.java/
> insgesamt 20K
> drwxr-xr-x3 root root 4,0K 2011-12-01 16:20 .
> drwxr-xr-x. 144 root root  12K 2011-12-02 20:14 ..
> drwxr-xr-x2 root root 4,0K 2011-11-28 20:21 .systemPrefs
>
> -- Start Rootkit Hunter Scan --
> Warning: Hidden directory found: /etc/.java
>

For openjdk, I added this 'fix' to address bug 741821 [1]. You can look 
at the bug for details, but essentially this is just making explicit 
what the software was expecting (or using) all along.

You are right that the hidden directories are a bad idea, but this is 
what the code in openjdk6 uses and we are (sort of) stuck with this - 
mostly because of backwards compatibility. Going forwards, I agree that 
we should fix this properly by using non-hidden directories, but this 
would probably be done only in the openjdk8 time frame.

Cheers,
Omair

[1] https://bugzilla.redhat.com/show_bug.cgi?id=741821
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: java-1.7.0-openjdk breaks java detection in LibreOffice?

2011-10-26 Thread Omair Majid
On 10/26/2011 06:58 PM, Dr Andrew John Hughes wrote:
> On 19:58 Wed 26 Oct , Heiko Adams wrote:
>> Am 26.10.2011 19:06, schrieb Jared K. Smith:
>>> On Wed, Oct 26, 2011 at 12:50 PM, Heiko Adams
>>>   wrote:
 is it just me or is java-1.7.0-openjdk breaking LibreOffice java
 detection?
>>>
>>> Sounds like it might be related to bug 748585.
>>>
>>
>> That would explain why java-1.7.0 isn't found by LO but not why
>> java-1.7.0 "hides" java-1.6.0. But on the other hand java-1.7.0 is
>> just some kind of technical preview.
>>
>
> No it isn't.  1.7 has been released and is final.
>
> http://blogs.oracle.com/javase/entry/java_7_has_released
>

Even though upstream considers it final, Fedora 16 only includes 
java-1.7.0-openjdk as a tech preview:
http://fedoraproject.org/wiki/Features/Java7TechPreview

Cheers,
Omair
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Jmol, Java and netscape.javascript

2011-08-23 Thread Omair Majid

On 08/23/2011 04:44 AM, Jussi Lehtola wrote:

$ ant -lib %{_datadir}/icedtea-web/plugin.jar doc main
doesn't work, it still fails in the same error.


There are two things that were causing problems. The spec file was 
setting classpath to a directory, not a jar. Also, the build.xml file 
was instructing ant to discard the classpath specified on the command line.


I have attached two patches (made against f16, and contain some extra 
debugging commands). I started off a build using them:


https://koji.fedoraproject.org/koji/taskinfo?taskID=3296091

The build failed, but it managed to compile at least some of the java 
code without the JSObject errors.


Cheers,
Omair
diff --git a/jmol.spec b/jmol.spec
index d651f23..62179b4 100644
--- a/jmol.spec
+++ b/jmol.spec
@@ -1,6 +1,6 @@
 Name:  jmol
 Version:   12.0.48
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:   An open-source Java viewer for chemical structures in 3D
 Group: Applications/Engineering
 License:   LGPLv2+
@@ -15,6 +15,8 @@ Patch0:   jmol-12.0.41-fedorabuild.patch
 Patch1:jmol-12.0.41-jarlocation.patch 
 # Don't try to sign jars
 Patch2:jmol-12.0.41-dontsign.patch
+# Dont ignore the system classpath
+Patch3: do-not-ignore-classpath.patch
 
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
@@ -67,6 +69,7 @@ The documentation for %{name}.
 %patch0 -p1 -b .fedorabuild
 %patch1 -p1 -b .jarlocation
 %patch2 -p1 -b .nosign
+%patch3 -p0
 
 # Remove binaries
 find -name '*.class' -exec rm -f '{}' \;
@@ -97,9 +100,10 @@ Categories=Education;Science;Chemistry;Physics;DataVisualization;
 EOF
 
 %build
-# Need to be able to find netscape.javascript.JSObject
-export CLASSPATH=%{_datadir}/icedtea-web
-ant doc main
+# Need to be able to find netscape.javascript.*classes
+PLUGIN_JAR=%{_datadir}/icedtea-web/plugin.jar
+jar tf $PLUGIN_JAR | grep JSObject
+ant --execdebug -lib $PLUGIN_JAR doc main
 
 %install
 rm -rf %{buildroot}
--- build.xml.orig	2011-08-23 13:30:34.0 -0400
+++ build.xml	2011-08-23 13:30:43.0 -0400
@@ -14,7 +14,6 @@
   
   
   
-  
   
   
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Jmol, Java and netscape.javascript

2011-08-17 Thread Omair Majid
On 08/17/2011 12:22 PM, Jussi Lehtola wrote:
> Hi,
>
> I tried to update Jmol to the latest release, when I ran once again
> into
>
> error: package netscape.javascript does not exist
> import netscape.javascript.JSObject;
>

The package is not standard part of Java. It is provided by plugin.jar. 
In Fedora <= 15 plugin.jar was included with the JDK (if the 
java-1.6.0-openjdk-plugin package was installed). Now plugin.jar is 
provided by icedtea-web.

> My spec builds fine in Fedora 15, but fails to build in 16 and 17.
> http://pkgs.fedoraproject.org/gitweb/?p=jmol.git;a=blob;f=jmol.spec;hb=HEAD
>
> Does someone have a solution to this problem?

I think one possible fix would be to BuildRequire icedtea-web and 
include /usr/share/icedtea-web/plugin.jar in the classpath.

HTH,
Omair
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Java 7 for Fedora 16

2011-07-29 Thread Omair Majid
On 07/25/2011 04:04 PM, Deepak Bhole wrote:
> * Bill Nottingham  [2011-07-25 15:54]:
>> Toshio Kuratomi (a.bad...@gmail.com) said:
>>> Robyn and I have talked about how the feature process could be adapted to
>>> allow for more late work to occur however none of that talk has turned into
>>> anything solid yet.  One point that bears on this is that the Feature Owners
>>> must be willing to commit to doing all the work involved in coordination
>>> when they submit something late.  In other words, if Java 7 update went in
>>> well before the feature deadline, the expectation would be that packagers
>>> whose packages depended on Java would need to adapt to Java 7.  The
>>> expectation now that the Feature Freeze has passed is that the people
>>> pushing Java 7 into the repos would also need to seek out and fix all the
>>> packages that depend on them that are broken.
>>
>> Would we actually be shipping only 7, or both 6 and 7?
>>
>
> This hasn't been debated yet, but I am very much in favour of having
> only 7 in Fedora 16.
>
> If the reason for asking was w.r.t re-builds, it is unlikely that most
> applications will need a rebuild -- only those using deprecated APIs
> (which would have been deprecated for years now) and private APIs would
> be affected. That would likely be a small subset.

Have you seen the list of incompatibilities?

http://www.oracle.com/technetwork/java/javase/compatibility-417013.html

Cheers,
Omair
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Taking ownership of netbeans and its dependencies

2010-12-23 Thread Omair Majid
Hi,

I would like to take ownership of the following orphaned packages:
appframework
beansbinding
bindex
freemarker
ini4j
javahelp2
jemmy
netbeans
netbeans-javaparser
netbeans-platform
netbeans-resolver
netbeans-svnclientadapter
swingx

Comaintainers are welcome!

Cheers,
Omair
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Licensing Guidelines Update - Please Read

2010-07-08 Thread Omair Majid

On 07/07/2010 04:29 PM, Tom "spot" Callaway wrote:
> [omajid] dbus-java: dbus-java-javadoc-2.7-3.fc13.noarch
> [omajid] libmatthew-java: libmatthew-java-javadoc-0.7.2-2.fc13.x86_64

Fixed in rawhide.

Cheers,
Omair
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel