Re: [fedora-arm] Re: Fedora 32 Mass Rebuild - fpc bootstrap on aarch64

[Dan Horák]

On Tue, 28 Jan 2020 02:23:10 -
"Artur Iwicki"  wrote:

> No, this was done on a Fedora install. But thanks for the input! I've
> looked into the sources and with patched paths and rebuilt bootstrap
> compiler, the koji scratch build went ok. Gonna make a commit to
> dist-git soon.

awesome, thanks Artur. I have updated fpc-srpm-macros and we should be
ready for the mass rebuild.


Dan
___
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

Review swaps (antlr4 reboot)

[Jerry James]

Greetings,

The antlr4 package needs a reboot so that it can ship the various
language runtime libraries, and so that it can be updated to the
latest version.  I have been in contact with the maintainers of the
current antlr4 package and have received approval to proceed with
this.

I would like to swap reviews for the following:

treelayout: https://bugzilla.redhat.com/show_bug.cgi?id=1795467
This package was previously in Fedora, but was retired after being
orphaned.  It has been retired long enough that a re-review is
necessary.

mojo-executor: https://bugzilla.redhat.com/show_bug.cgi?id=1795468

string-template-maven-plugin:
https://bugzilla.redhat.com/show_bug.cgi?id=1795469
Depends on mojo-executor.

antlr4-cpp-runtime: https://bugzilla.redhat.com/show_bug.cgi?id=1795470
Depends on treelayout and string-template-maven-plugin.  The funny
name is because, so far as I am aware, it is still not possible to
have a noarch main package with arch-specific subpackages.  I selected
one of the arch-specific language runtimes to be the main package, and
antlr4 itself (which is noarch) is a subpackage.  Once this package is
in Rawhide, the existing antlr4 package will be retired and the
antlr4-python3-runtime subpackage will be removed from the coq
package.

Thanks in advance.  Regards,
-- 
Jerry James
http://www.jamezone.org/
___
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: Java Checkstyle Blocked Even Though Build was Successful

[Scott Talbert]

On Tue, 28 Jan 2020, Bill Chatfield via devel wrote:


Are any of you on the java-devel list so that I could move my newb questions
there? I can guarantee that it's a low-traffic list so there's no risk in
joining it.   :-)

google-http-java-client looks easy to fix. It won't build because it needs
one dependency, maven-checkstyle-plugin, which won't build because it needs
one dependency, checkstyle. But, checkstyle is blocked even though built
successfully the last time.

So, all three packages look unnecessarily blocked.


checkstyle was retired because it was orphaned for 6+ weeks.  I don't know 
why it was orphaned, but since it was retired 6 months ago, it will have 
to be re-reviewed to come back.


Scott___
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

Java Checkstyle Blocked Even Though Build was Successful

[Bill Chatfield via devel]

Are any of you on the java-devel list so that I could move my newb questions 
there? I can guarantee that it's a low-traffic list so there's no risk in 
joining it.   :-)
google-http-java-client looks easy to fix. It won't build because it needs one 
dependency, maven-checkstyle-plugin, which won't build because it needs one 
dependency, checkstyle. But, checkstyle is blocked even though built 
successfully the last time.
So, all three packages look unnecessarily blocked.
Now tell me how wrong I am.   :-)
___
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

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2020-01-28 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open&tags=Meeting).



Source: https://apps.fedoraproject.org/calendar/meeting/9480/

___
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: Groovy Build Failing Due to Disappearance of groovy-local

[Bill Chatfield via devel]

I guess an outdated package might be easier but I'm more concerned about the 
ones that are broken. I suppose the ones that are broken are still broken 
because they're hard to fix.
___
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-arm] Re: Fedora 32 Mass Rebuild - fpc bootstrap on aarch64

[Artur Iwicki]

No, this was done on a Fedora install. But thanks for the input! I've looked 
into the sources and with patched paths and rebuilt bootstrap compiler, the 
koji scratch build went ok. Gonna make a commit to dist-git soon.
___
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

List of long term FTBFS packages to be retired in a week

[Miro Hrončok]

Dear maintainers.

Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching 
(2020-02-03).

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 30.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


There is an open exception request for shim-unsigned-aarch64 and 
shim-unsigned-x64, but it has not yet been approved -- if it gains no negative 
votes within 1 day, it will be:

https://pagure.io/fesco/issue/2331

If you see a package that can be rebuilt, please do so.

 Package  (co)maintainers   Latest build

elasticsearch hubbitus, jvanek, lbazan,Fedora 24
   zbyszek
expresso  jamielinux, nodejs-sig,  Fedora 28
   patches
libocrdma ocrdma   Fedora 27
nuvola-app-google-calendarmartinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media-martinkg Fedora 29
server
nuvola-app-plex   martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music   martinkg Fedora 29
shim-unsigned-aarch64 pjones (exception request)   Fedora 28
shim-unsigned-x64 pjones (exception request)   Fedora 28

The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2

Affected (co)maintainers
hubbitus: elasticsearch
jamielinux: expresso
jvanek: elasticsearch
lbazan: elasticsearch
martinkg: nuvola-app-soundcloud, nuvola-app-logitech-media-server, 
nuvola-app-yandex-music, nuvola-app-groove, nuvola-app-google-calendar, 
nuvola-app-plex

nodejs-sig: expresso
ocrdma: libocrdma
patches: expresso
pjones: shim-unsigned-aarch64, shim-unsigned-x64
tomh: expresso
zbyszek: elasticsearch

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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 packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-01-27.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers  Status Change
===
argyllcms orphan, rhughes 0 weeks ago
exciting  marcindulak, orphan 1 weeks ago
htmlcleaner   besser82, marcindulak, orphan   1 weeks ago
java-augeas   bkearney, orphan0 weeks ago
jboss-transaction-1.2-api orphan  2 weeks ago
jettison  mizdebsk, orphan2 weeks ago
jetty-artifact-remote-resources   mizdebsk, orphan2 weeks ago
jetty-assembly-descriptorsmizdebsk, orphan2 weeks ago
jetty-test-policy mizdebsk, orphan2 weeks ago
maven-jarsigner-pluginjcapik, mizdebsk, orphan0 weeks ago
maven-shared-jarsignermizdebsk, orphan0 weeks ago
perl-Time-Piece-MySQL orphan  0 weeks ago
python-slackerorphan, python-sig, raphgro 2 weeks ago
rubygem-faker orphan  4 weeks ago
rubygem-pam   bkearney, orphan0 weeks ago
slack-cleaner orphan  2 weeks ago
sound-theme-acoustic  orphan  4 weeks ago
sugar-moonbkearney, orphan0 weeks ago
sugar-turtleart   bkearney, erikos, orphan, sdz   0 weeks ago
swingxorphan  3 weeks ago
tudu  orphan  4 weeks ago

The following packages require above mentioned packages:
Depending on: argyllcms (1), status change: 2020-01-22 (0 weeks ago)
foo2zjs (maintained by: cjatherton)
foo2zjs-0.20170412-12.fc31.x86_64 requires argyllcms = 
1.9.2-8.fc31

Depending on: maven-jarsigner-plugin (1), status change: 2020-01-26 (0 weeks 
ago)
jetty-test-policy (maintained by: mizdebsk, orphan)
		jetty-test-policy-1.2-22.fc31.src requires 
mvn(org.apache.maven.plugins:maven-jarsigner-plugin) = 1.4


Depending on: maven-shared-jarsigner (2), status change: 2020-01-26 (0 weeks 
ago)
maven-jarsigner-plugin (maintained by: jcapik, mizdebsk, orphan)
		maven-jarsigner-plugin-1.4-9.fc31.noarch requires 
mvn(org.apache.maven.shared:maven-jarsigner) = 1.3.2
		maven-jarsigner-plugin-1.4-9.fc31.src requires 
mvn(org.apache.maven.shared:maven-jarsigner) = 1.3.2


jetty-test-policy (maintained by: mizdebsk, orphan)
		jetty-test-policy-1.2-22.fc31.src requires 
mvn(org.apache.maven.plugins:maven-jarsigner-plugin) = 1.4


Depending on: perl-Time-Piece-MySQL (47), status change: 2020-01-23 (0 weeks 
ago)
perl-Class-DBI (maintained by: spot)
perl-Class-DBI-3.0.17-33.fc31.src requires 
perl(Time::Piece::MySQL) = 0.06

perl-Class-DBI-mysql (maintained by: spot)
		perl-Class-DBI-mysql-1.00-35.fc31.noarch requires perl(Class::DBI) = 3.0.17, 
perl(Time::Piece::MySQL) = 0.06

perl-Class-DBI-mysql-1.00-35.fc31.src requires perl(Class::DBI) 
= 3.0.17

perl-DBIx-Class (maintained by: iarnell, jplesnik, ppisar, tremble)
		perl-DBIx-Class-0.082841-9.fc31.src requires perl(Class::DBI) = 3.0.17, 
perl(Class::DBI::Column), perl(Time::Piece::MySQL) = 0.06


perl-Apache-DBI-Cache (maintained by: eseyman, holcapek)
perl-Apache-DBI-Cache-0.08-35.fc31.src requires 
perl(Class::DBI) = 3.0.17

perl-Class-DBI-AbstractSearch (maintained by: spot)
		perl-Class-DBI-AbstractSearch-0.07-35.fc31.noarch requires perl(Class::DBI) = 
3.0.17

perl-Class-DBI-AbstractSearch-0.07-35.fc31.src requires 
perl(Class::DBI) = 3.0.17

perl-Class-DBI-AsForm (maintained by: spot)
perl-Class-DBI-AsForm-2.42-39.fc31.noarch requires 
perl(Class::DBI) = 3.0.17
perl-Class-DBI-AsForm-2.42-39.fc31.src requires 
perl(Class::D

License change for rust-x11

[Josh Stone]

rust-x11-2.18.2-1.fc32 hash changed its license from CC0-1.0 to MIT.
See also: https://github.com/erlepereira/x11-rs/issues/82
___
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: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

That is a very helpful explanation. I do have a lot of repos configured but 
most are necessary. Some are now added by gnome-software.

_copr_phracek-PyCharm.repo   fedora-updates.repo  
rpmfusion-nonfree-nvidia-driver.repo
dropbox.repo fedora-updates-testing-modular.repo  
rpmfusion-nonfree.repo
fedora-cisco-openh264.repo   fedora-updates-testing.repo  
rpmfusion-nonfree-steam.repo
fedora-modular.repo  google-chrome.repo   
rpmfusion-nonfree-updates.repo
fedora.repo  rpmfusion-free.repo  
rpmfusion-nonfree-updates-testing.repo
fedora-spotify.repo  rpmfusion-free-updates.repo
fedora-updates-modular.repo  rpmfusion-free-updates-testing.repo

I added these to /etc/dnf/dnf.conf based on googling;
max_parallel_downloads=10
ip_resolve=4
keepcache=true
deltarpm=true


___
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: Java Dev Group and Fedora Quality

[Neal Gompa]

On Mon, Jan 27, 2020 at 1:44 PM Mario Torre  wrote:
>
> On Mon, Jan 27, 2020 at 7:11 PM Robbie Harwood  wrote:
>
> > Java packaging being extremely difficult is not a Fedora-specific
> > problem.  The modularity effects are, but the packaging has been
> > known-hard for a very long time in many distros (and even outside a
> > distro context, it's not fun to work with the Java package managers).
>
> Distribution of java libraries and sometime applications is a problem
> that the Java community has solved (arguably with mixed results and
> not completely) with the use of maven, and most of the de-facto
> standard solutions evolve around some use of maven for deployment and
> shipping of the dependencies required to run and build end
> applications.
>
> Fedora, for some reason that may have been understandable 15 years ago
> but that clearly show the sign of time and the drawbacks decided to go
> through a different form of distribution and instead of embracing
> maven as a native tool for java packages has wrapped everything around
> RPM, because this was how the rest was distributed. Of course, this
> made sense as I said, you want to have one way central way and one
> tool with one familiar interface to build up your distribution and OS,
> but in hindsight I can't help thinking that it would have been better
> to teach RPM about maven instead, after all xmvn is just an hack to do
> exactly that.
>
> There are a few things that can be done to improve this situation
> going forward, some of those ideas may include things like dropping
> RPM packages completely, use flatpaks, create a properly audited
> deployment channel similar to what maven central does but more
> controlled and closed world, etc...
>

Honestly, the correct thing is to make it so the maven to RPM
interface is as transparent as possible. We've done a reasonably good
job with this in Rust, Ruby, and Python, and the situation is (slowly)
improving in Go. But nobody has sat down and looked at what we have in
RPM today and taken a fresh look at how Java packaging *could* work. I
think you underestimate the value of having Java components shipped as
RPMs, but I'm not surprised, as you've probably never had to actually
be forced to audit the usage of Java components in various
applications and justify them. It's a lot easier to do when the
components are de-duplicated and used in a meaningfully uniform
manner. Also, RPM distribution is loads easier than dealing with the
disaster that is private Maven repositories.

Riffing off what Florian had for his DevConf.cz talk title,
JPackage/RPM Java is basically packaging like it's 1999. The rest of
the ecosystems are moving forward. Java has not. And I think that's
where a lot of the pain exists.

But without interest or investment from the Java stack packagers at
Red Hat, there's basically no way to get a redesign of Java packaging
done, much less even on the table.




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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-arm] Re: Fedora 32 Mass Rebuild - fpc bootstrap on aarch64

[Florian Weimer]

* Artur Iwicki:

> If you're asking "what's the source code", then it's built using the same 
> source as the RPM. After going through %setup (i.e. extracting everything and 
> applying patches), do:
> $ cd fpcsrc/
> $ make all CPU_TARGET=aarch64 OS_TARGET=linux 
> BINUTILSPREFIX=aarch64-linux-gnu-
>
> If you're asking "where the binary comes from", then I've
> cross-compiled it (as described above) on my x86_64 machine.

Was this a Debian box by chance?  Or perhaps the paths are hard-coded
incorrectly in the sources?  Then you will have to patch them in
fpcsrc/compiler/systems/t_linux.pas before building the cross-compiler.

The bootstrap binary contains multi-arch paths only:

/usr/local/lib/fpc/
/usr/lib/fpc/
=/lib;=/usr/lib;=/usr/X11R6/lib
=/usr/lib/aarch64-linux-gnu
=/usr/lib

On Fedora, there should be /usr/lib64 there.  Not sure why the warning
about the missing crti.o file isn't printed, though.


Thanks,
Florian
___
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 Mass Rebuild

[Jeff Law]

On Mon, 2020-01-27 at 21:23 +0100, Fabio Valentini wrote:
> On Mon, Jan 27, 2020 at 4:46 PM Jeff Law  wrote:
> > On Mon, 2020-01-27 at 16:34 +0100, Jakub Jelinek wrote:
> > > On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote:
> > > > Hi all,
> > > > 
> > > > Per the Fedora 32 schedule[1] we will be starting a mass rebuild for
> > > > Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the
> > > > changes:
> > > > 
> > > > https://fedoraproject.org/wiki/Changes/GLIBC231
> > > > https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33
> > > > https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
> > > > https://fedoraproject.org/wiki/Changes/golang1.14
> > > > https://fedoraproject.org/wiki/Changes/GCC10
> > > > https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0
> > > > 
> > > > we will start the mass rebuild on 2020-01-27
> > > 
> > > I thought the mass rebuild should be also for
> > > https://fedoraproject.org/wiki/LTOByDefault
> > > but the required changes AFAIK haven't landed into redhat-rpm-config yet.
> > > 
> > > CCing Jeff on the current state.
> 
> (snip)
> 
> > After finally starting looking at the LTO vs GDB issues last week, I
> > think we should defer LTO until F33.  There's just too many GDB
> > failures when used with LTO that aren't understood yet.
> 
> Since the mass rebuild starts today (or has already started), you're
> cutting it pretty close there ...
> 
> So you'll either need to postpone to F33 or request a second mass
> rebuild - soon.
> 
> Can you comment on the FESCo ticket with the current status? Just to
> keep us in the loop
Umm, Ben and I were already discussing the situation this morning.  I
believe the page and fesco ticket both have current state (deferring to
F33).

jeff
> 
___
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 Mass Rebuild

[Artur Iwicki]

I've finished the build for ppc64le (bootstrapped from a cross-compiled 
compiler): https://koji.fedoraproject.org/koji/taskinfo?taskID=41106187

It should be noted, though, that to enable ppc64le for dependent packages, the 
fpc-srpm-macros package must be edited (since packages depending on fpc use the 
%{fpc_arches} macro defined there).
___
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 Mass Rebuild

[Dan Horák]

On Mon, 27 Jan 2020 22:12:41 +0100
Fabio Valentini  wrote:

> On Mon, Jan 27, 2020 at 10:06 PM Dan Horák  wrote:
> >
> > On Mon, 27 Jan 2020 15:59:37 -0500
> > Mohan Boddu  wrote:
> >
> > > Dan and Artur,
> > >
> > > The mass rebuild hasn't started yet, I can wait until 08:00 UTC
> > > 28-Jan-2020 before starting the mass rebuild.
> > >
> > > If the work is not done by then, we have to run a selective
> > > rebuild later.
> >
> > I don't think we can fix it before the morning tomorrow. Artur, I
> > suggest to do a build with the ppc64le bootstrap included and fix
> > aarch64 later.
> 
> Sorry if this is a stupid question, but won't the build just fail if
> aarch64 fails? So it won't get used for the mass rebuild at all?

it won't fail because aarch64 will be still ExcludeArch-ed, only
ppc64le would be added to the "working arches"


Dan
 
> Fabio
> 
> > Dan
> >
> > >
> > > CC'ing Ben.
> > >
> > > Thanks.
> > >
> > > On Mon, Jan 27, 2020 at 3:11 PM Artur Iwicki
> > >  wrote:
> > > >
> > > > Here's a koji scratch build:
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=41102368
> > > >
> > > > The ppc64le bootstrap went fine, the aarch64 one fails at:
> > > > /builddir/build/BUILD/fpcbuild-r1430/fpcsrc/compiler/ppca64
> > > > fpmake.pp -n
> > > > -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/packages/fpmkunit/units_bs/aarch64-linux
> > > > -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/rtl/units/aarch64-linux
> > > > -k"--build-id" /usr/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS):
> > > > in function `__libc_csu_init': (.text+0x38): undefined
> > > > reference to `_init'
> > > > ___ 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
> > > ___
> > > 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
> > ___
> > 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
> ___
> 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
___
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 Mass Rebuild

[Fabio Valentini]

On Mon, Jan 27, 2020 at 10:06 PM Dan Horák  wrote:
>
> On Mon, 27 Jan 2020 15:59:37 -0500
> Mohan Boddu  wrote:
>
> > Dan and Artur,
> >
> > The mass rebuild hasn't started yet, I can wait until 08:00 UTC
> > 28-Jan-2020 before starting the mass rebuild.
> >
> > If the work is not done by then, we have to run a selective rebuild
> > later.
>
> I don't think we can fix it before the morning tomorrow. Artur, I
> suggest to do a build with the ppc64le bootstrap included and fix
> aarch64 later.

Sorry if this is a stupid question, but won't the build just fail if
aarch64 fails? So it won't get used for the mass rebuild at all?

Fabio

> Dan
>
> >
> > CC'ing Ben.
> >
> > Thanks.
> >
> > On Mon, Jan 27, 2020 at 3:11 PM Artur Iwicki 
> > wrote:
> > >
> > > Here's a koji scratch build:
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=41102368
> > >
> > > The ppc64le bootstrap went fine, the aarch64 one fails at:
> > > /builddir/build/BUILD/fpcbuild-r1430/fpcsrc/compiler/ppca64
> > > fpmake.pp -n
> > > -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/packages/fpmkunit/units_bs/aarch64-linux
> > > -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/rtl/units/aarch64-linux
> > > -k"--build-id" /usr/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS):
> > > in function `__libc_csu_init': (.text+0x38): undefined reference to
> > > `_init' ___ 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
> > ___
> > 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
> ___
> 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
___
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 Mass Rebuild

[Dan Horák]

On Mon, 27 Jan 2020 15:59:37 -0500
Mohan Boddu  wrote:

> Dan and Artur,
> 
> The mass rebuild hasn't started yet, I can wait until 08:00 UTC
> 28-Jan-2020 before starting the mass rebuild.
> 
> If the work is not done by then, we have to run a selective rebuild
> later.

I don't think we can fix it before the morning tomorrow. Artur, I
suggest to do a build with the ppc64le bootstrap included and fix
aarch64 later.


Dan

> 
> CC'ing Ben.
> 
> Thanks.
> 
> On Mon, Jan 27, 2020 at 3:11 PM Artur Iwicki 
> wrote:
> >
> > Here's a koji scratch build:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=41102368
> >
> > The ppc64le bootstrap went fine, the aarch64 one fails at:
> > /builddir/build/BUILD/fpcbuild-r1430/fpcsrc/compiler/ppca64
> > fpmake.pp -n
> > -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/packages/fpmkunit/units_bs/aarch64-linux
> > -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/rtl/units/aarch64-linux
> > -k"--build-id" /usr/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS):
> > in function `__libc_csu_init': (.text+0x38): undefined reference to
> > `_init' ___ 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
> ___
> 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
___
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 Mass Rebuild

[Mohan Boddu]

Dan and Artur,

The mass rebuild hasn't started yet, I can wait until 08:00 UTC
28-Jan-2020 before starting the mass rebuild.

If the work is not done by then, we have to run a selective rebuild later.

CC'ing Ben.

Thanks.

On Mon, Jan 27, 2020 at 3:11 PM Artur Iwicki  wrote:
>
> Here's a koji scratch build: 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41102368
>
> The ppc64le bootstrap went fine, the aarch64 one fails at:
> /builddir/build/BUILD/fpcbuild-r1430/fpcsrc/compiler/ppca64 fpmake.pp -n 
> -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/packages/fpmkunit/units_bs/aarch64-linux
>  -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/rtl/units/aarch64-linux  
> -k"--build-id"
> /usr/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS): in function 
> `__libc_csu_init':
> (.text+0x38): undefined reference to `_init'
> ___
> 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
___
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-arm] Re: Fedora 32 Mass Rebuild - fpc bootstrap on aarch64

[Dan Horák]

On Mon, 27 Jan 2020 20:28:15 -
"Artur Iwicki"  wrote:

> If you're asking "what's the source code", then it's built using the
> same source as the RPM. After going through %setup (i.e. extracting
> everything and applying patches), do: $ cd fpcsrc/ $ make all
> CPU_TARGET=aarch64 OS_TARGET=linux BINUTILSPREFIX=aarch64-linux-gnu-
> 
> If you're asking "where the binary comes from", then I've
> cross-compiled it (as described above) on my x86_64 machine.

yes, the latter has been my question


Dan
___
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: How to handle circular build dependencies?

[Richard W.M. Jones]

On Mon, Jan 27, 2020 at 06:43:36PM +0200, Markku Korkeala wrote:
> Hi,
> 
> sorry if this a newbie question, I tried to search this
> but did not find good documentation on this problem.
> 
> I'm in the process of upgrading the clojure package to
> next version, which has new dependencies. These dependencies
> require certain clojure version themselves, so it makes a
> chicken-and-egg kind of problem. Are there good ways to handle
> these kind of circular dependencies?

Not really, I think you'll end up building at least
one package twice.

I think it's Perl where IIRC the package can be configured
as a bootstrap package (by setting an RPM variable), built
that way, the dependencies are then built, then the perl
package is flipped back to non-bootstrap mode and built a
second time against those just built dependencies.

If you do it all in a side tag then no one will see the
intermediate packages.

> I know I can update clojure to certain alpha version,
> which the new libraries require. Then build those,
> and when they are accepted then upgrade the
> clojure package, and then upgrade those libraries, etc. But
> it is tedious. I'm hoping there would be a better
> way :)

Is it possible to build a "cut down" clojure which
doesn't need the dependencies (ie that would be the
bootstrap version)?

> And also do I have to do that bootstrapping
> again when building clojure for example EPEL-8?

Probably :-)

IMHO it helps to script Koji builds.  We don't have any official
tooling for that as far as I'm aware, but various people have built
unofficial tools including me (see
https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-which-generalizes-make/
http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=summary)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
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: Java Dev Group and Fedora Quality

[Przemek Klosowski via devel]

On 1/26/20 5:33 PM, Bill Chatfield via devel wrote:

When I type "sudo dnf install something" it takes about 10 minutes to pull 
updates from every repository, every time I run dnf. The actual install or update 
proceeds at a reasonable pace. I wouldn't call it fast. I could send you a video of this 
if you'd like. I see this on all my machines and I see other people complaining about it 
too.

In contrast, if I type "sudo apt install something" on Ubuntu or Debian, a 
bunch of text goes by really fast and BAM, it's done...


How many repositories do you use (dnf repolist)? One trap I repeatedly 
fall in is to enable a special-purpose repo which then falls into 
disrepair or disappears---but yum still gets bogged down accessing it.


Historically, the Fedora/RedHat/Centos ecosystem evolved to have a great 
many repositories: Fedora, rpmfusion-free/nonfree, base/EPEL/extras for 
Centos, RHEL/EPEL for RedHat. This is a headache for everyone who 
manages a heterogeneous collection of computers, and often results in 
slow and often unpredictable operation because of so many combinations 
of the instantaneous mirroring situation. The reason for that was 
sometimes political (Fedora Free vs non-free repositories), sometimes 
business-related (RedHat repos are only available to subscribers) and 
sometimes technical/historical/other (EPEL vs extras).


In contrast, Debian has a simple repository scheme, and I think their 
packaging system uses less metadata, resulting in fast operation. One 
frustrating aspect of yum/dnf is that often it takes significant time to 
download the metadata updates, just to find out that there are no 
package updates to apply.


I think people have been discussing ideas for more granular and faster 
metadata updates, but it's a hairy problem due to a lot of history and 
backward compatibility issues.

___
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-arm] Re: Fedora 32 Mass Rebuild - fpc bootstrap on aarch64

[Artur Iwicki]

If you're asking "what's the source code", then it's built using the same 
source as the RPM. After going through %setup (i.e. extracting everything and 
applying patches), do:
$ cd fpcsrc/
$ make all CPU_TARGET=aarch64 OS_TARGET=linux BINUTILSPREFIX=aarch64-linux-gnu-

If you're asking "where the binary comes from", then I've cross-compiled it (as 
described above) on my x86_64 machine.
___
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 Mass Rebuild

[Fabio Valentini]

On Mon, Jan 27, 2020 at 4:46 PM Jeff Law  wrote:
>
> On Mon, 2020-01-27 at 16:34 +0100, Jakub Jelinek wrote:
> > On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote:
> > > Hi all,
> > >
> > > Per the Fedora 32 schedule[1] we will be starting a mass rebuild for
> > > Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the
> > > changes:
> > >
> > > https://fedoraproject.org/wiki/Changes/GLIBC231
> > > https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33
> > > https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
> > > https://fedoraproject.org/wiki/Changes/golang1.14
> > > https://fedoraproject.org/wiki/Changes/GCC10
> > > https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0
> > >
> > > we will start the mass rebuild on 2020-01-27
> >
> > I thought the mass rebuild should be also for
> > https://fedoraproject.org/wiki/LTOByDefault
> > but the required changes AFAIK haven't landed into redhat-rpm-config yet.
> >
> > CCing Jeff on the current state.

(snip)

> After finally starting looking at the LTO vs GDB issues last week, I
> think we should defer LTO until F33.  There's just too many GDB
> failures when used with LTO that aren't understood yet.

Since the mass rebuild starts today (or has already started), you're
cutting it pretty close there ...

So you'll either need to postpone to F33 or request a second mass
rebuild - soon.

Can you comment on the FESCo ticket with the current status? Just to
keep us in the loop

Thanks,
Fabio

> I have asked that the LTO bytecode stripping change get into redhat-
> rpm-config immediately though.  We already know some packages have
> enabled LTO and we want to make sure they don't leak the LTO bytecodes
> into the distro.
>
> jeff
> ___
> 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
___
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-arm] Re: Fedora 32 Mass Rebuild - fpc bootstrap on aarch64

[Dan Horák]

On Mon, 27 Jan 2020 21:19:34 +0100
Dan Horák  wrote:

> On Mon, 27 Jan 2020 20:11:07 -
> "Artur Iwicki"  wrote:
> 
> > Here's a koji scratch build:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=41102368
> > 
> > The ppc64le bootstrap went fine, the aarch64 one fails at:

what is the source of the bootstrap binary for aarch64?


Dan

> 
> /builddir/build/BUILD/fpcbuild-r1430/fpcsrc/compiler/ppca64 fpmake.pp
> -n
> -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/packages/fpmkunit/units_bs/aarch64-linux
> -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/rtl/units/aarch64-linux
> -k"--build-id" /usr/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS):
> in function `__libc_csu_init': (.text+0x38): undefined reference to
> `_init'
> 
> let's forward it to the arm list
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41102369 has a
> link to the srpm
> 
> 
>   Dan
> ___
> arm mailing list -- a...@lists.fedoraproject.org
> To unsubscribe send an email to arm-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/a...@lists.fedoraproject.org
___
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 Mass Rebuild - fpc bootstrap on aarch64

[Dan Horák]

On Mon, 27 Jan 2020 20:11:07 -
"Artur Iwicki"  wrote:

> Here's a koji scratch build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41102368
> 
> The ppc64le bootstrap went fine, the aarch64 one fails at:

/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/compiler/ppca64 fpmake.pp -n 
-Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/packages/fpmkunit/units_bs/aarch64-linux
 -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/rtl/units/aarch64-linux 
-k"--build-id"
/usr/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS): in function 
`__libc_csu_init':
(.text+0x38): undefined reference to `_init'

let's forward it to the arm list

https://koji.fedoraproject.org/koji/taskinfo?taskID=41102369 has a link
to the srpm


Dan
___
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 Mass Rebuild

[Artur Iwicki]

Here's a koji scratch build: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=41102368

The ppc64le bootstrap went fine, the aarch64 one fails at:
/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/compiler/ppca64 fpmake.pp -n 
-Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/packages/fpmkunit/units_bs/aarch64-linux
 -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/rtl/units/aarch64-linux  
-k"--build-id"
/usr/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS): in function 
`__libc_csu_init':
(.text+0x38): undefined reference to `_init'
___
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: Java Dev Group and Fedora Quality

[Fabio Valentini]

On Mon, Jan 27, 2020 at 6:01 PM Mario Torre  wrote:
>
> On Mon, Jan 27, 2020 at 5:28 PM Robbie Harwood  wrote:
>
> > > You would not expect a GCC devroom to be concerned about the problems
> > > of all packages written in C and C++, so why would Java be any
> > > different?
> >
> > Honestly?  I totally would expect that.  Wouldn't that be better for
> > everyone?
> >
> > Compilers aren't special here: every package that wishes to continue to
> > have users *needs* to care about those users.  Maintenance and features
> > need to be tailored to actual use cases.  Otherwise, it's a waste of
> > time, and just further irritates said users.
>
> That's not the place for such discussions, this is not a problem that
> is general to Java (and wouldn't be general to the C or C++ languages
> in the case of the GCC example above), is specific to Fedora and even
> more specific to some of the packages and needs to be addressed within
> the Fedora community. If there are problems that leak upstream in
> terms of patching requirements the maintainers (and perhaps the
> package users) have the duty to carry this work, you can't expect the
> rest of the world to discuss those issues during a developer
> conference dedicated to the programming language and its development,
> even when there is a mild overlap in interest because some of the
> involved people are the same, and neither you can draw conclusions on
> the interests of the Red Hat Java leadership based on the schedule
> alone.
>
> To get back on topic, I don't have the feeling that the java packaging
> is so dismantled, and I use java packages from RHEL and Fedora often,
> but I do know there's a series of problems with some of the packages,
> and I understand from this thread that some of the issues stem from
> the decision to use modules (sorry, I don't make the rules here, and
> while I also don't understand why modules are such a hot topic I can't
> help on the merit). Now, a constructive discussion would go toward
> suggestions on how to fix those problems not focus on pointless
> deliberation on what or how the Java DevRoom should be run and whether
> it should transform into a Fedora Java Packaging DevRoom.

(snip)

> So, what are your suggestions, and what can we do to help?
>

You want to know how to help improve the Java stack in fedora?

Well, the Stewardship SIG is now basically the home of the RPM Java
stack, minus eclipse.
But we've been working together with mbooth to get eclipse into shape, as well.

So you can look at our tracking project to see what we're working on:
https://pagure.io/stewardship-sig/

There's some reports that I generate daily, which contain package
dependency information, open pull requests, and update backlogs:
- report: https://decathorpe.fedorapeople.org/stewardship-sig.html
- pull requests: https://decathorpe.fedorapeople.org/stewardship-sig-prs.html
- update backlogs:
https://decathorpe.fedorapeople.org/stewardship-sig-stats.html

There's also a spreadsheet for a "birds-eye view" of the packages we
maintain (which is most Java packages):
https://docs.google.com/spreadsheets/d/11RlwsEs-LJgTOrUD1P4LpsvW9icVQrvrU5RFqxUuccY/edit?usp=sharing

If anybody wants to help with Java packaging, these would be the
places where I would start:
- review our open Pull Requests,
- file Pull Requests for missing package updates,
- report issues with broken packages.

Keep in mind that we're only interested in non-modular Java packages.
Mikolaj is working on his Java modules, and sometimes we can benefit
from work he's already done there, but mostly the two ways of
packaging things have just diverged (since Mikolaj doesn't care about
non-modular packages anymore, and we don't want to futz around with
shiny Modularity).

If we get some people who are interested in keeping the Java stack in
fedora working, maybe we can even get the Java SIG off the ground
again.
The first step in that direction would be to delete the old and
outdated wiki page and start fresh ...

Fabio

PS: I don't even find Java packaging to be that difficult - unless
upstreams decide to do weird shit with maven - which you then have to
exorcise with XPATH voodoo. Or even better, if they hosted their
sources in SVN on Java.net or Google Code. :D

> Cheers,
> Mario
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH 
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> ___
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to de

Re: swap-on-ZRAM by default

[Rahul Sundaram]

Hi

On Mon, Jan 27, 2020 at 8:56 AM Zbigniew Jędrzejewski-Szmek wrote:

> It is "upstream" in the sense that it is under the same umbrella.
> There are no plans to move the code to the main repo, because it's in
> rust and currently combining meson which is used for systemd proper
> with rust and cargo is not very convenient.
>

A bit of a tangent but there was a proposal for systemd itself to start
using C++ at some point.  Was that or Rust still in consideration?

Rahul
___
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 Mass Rebuild

[Dan Horák]

On Mon, 27 Jan 2020 18:42:28 -
"Artur Iwicki"  wrote:

> Yes, sorry about that. I'm working on it right now. Should be done
> before midnight CET. 
> 
> FPC 3.2.0 was originally to come out before the end of 2019, but it
> still hasn't been released. Reading the forums and the bug tracker,
> none of the remaining issues affect Fedora, so I decided to go with
> 3.2.0-beta from the latest SVN revision. That's the main reason for
> this lag. Sorry once again.

and those are all objective reasons, so no problem. Let me know if you
need some help with the ppc64le (or aarch64) parts. Worst case we could
do a limited rebuild later.


Dan
___
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: Java Dev Group and Fedora Quality

[Emmanuel Seyman]

* Bill Chatfield via devel [26/01/2020 22:33] :
>
> I don't know if the problem is dnf or a library, but it is a serious problem.

There are several issues here:

- Different servers will transmit repository metadata at different speeds
  and you need to factor these out when trying to find bottleneck in the
  client-side code.
- dnf handles more stuff than apt. For instance, perl packages have virtual
  provides in the form of 'perl($MODULE)' for every perl module in the
  package.  This allows users to install a given module without caring
  what package it is in. Last I checked, apt had no equivalent.

Emmanuel
___
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: Let's talk about Fedora in the '20s!

[Jun Aruga]

> In my experience, in 1999 I was living in the same region with an NGO
> working for a backbone network.
> And the NGO helped me to put my Linux server in their network for free.
> In the age of non-democratized computer and internet, some
> organizations helped for the new technologies.

My mistake. Maybe it was not "NGO" but "NPO" (NonProfit Organization).

-- 
Jun | He - His - Him
___
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: Java Dev Group and Fedora Quality

[Mario Torre]

On Mon, Jan 27, 2020 at 7:11 PM Robbie Harwood  wrote:

> Java packaging being extremely difficult is not a Fedora-specific
> problem.  The modularity effects are, but the packaging has been
> known-hard for a very long time in many distros (and even outside a
> distro context, it's not fun to work with the Java package managers).

Distribution of java libraries and sometime applications is a problem
that the Java community has solved (arguably with mixed results and
not completely) with the use of maven, and most of the de-facto
standard solutions evolve around some use of maven for deployment and
shipping of the dependencies required to run and build end
applications.

Fedora, for some reason that may have been understandable 15 years ago
but that clearly show the sign of time and the drawbacks decided to go
through a different form of distribution and instead of embracing
maven as a native tool for java packages has wrapped everything around
RPM, because this was how the rest was distributed. Of course, this
made sense as I said, you want to have one way central way and one
tool with one familiar interface to build up your distribution and OS,
but in hindsight I can't help thinking that it would have been better
to teach RPM about maven instead, after all xmvn is just an hack to do
exactly that.

There are a few things that can be done to improve this situation
going forward, some of those ideas may include things like dropping
RPM packages completely, use flatpaks, create a properly audited
deployment channel similar to what maven central does but more
controlled and closed world, etc...

Yes, I can see how this sort of discussion would be interesting to
have during the devroom because it's definitely beyond just Fedora,
and I'm sure there will be also some discussion about that on the side
like always, but overall specific issues should be discussed where
they matter, so any issues specific to RPM packaging of Eclipse won't
really find its way in the Java DevRoom (but I know the Eclipse
developers would be happy to discuss some of those problems during/in
between their DevRoom:
https://fosdem.org/2020/schedule/track/free_tools_and_editors/ if you
happen to be there).

> > and neither you can draw conclusions on the interests of the Red Hat
> > Java leadership based on the schedule alone.
>
> (For what it's worth, I'm not interested in doing that which is why I
> trimmed the email the way I did, though I know Nicolas was.)

Acknowledged.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
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 Mass Rebuild

[Artur Iwicki]

Yes, sorry about that. I'm working on it right now. Should be done before 
midnight CET. 

FPC 3.2.0 was originally to come out before the end of 2019, but it still 
hasn't been released. Reading the forums and the bug tracker, none of the 
remaining issues affect Fedora, so I decided to go with 3.2.0-beta from the 
latest SVN revision. That's the main reason for this lag. Sorry once again.
___
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: Let's talk about Fedora in the '20s!

[Jun Aruga]

> First, I'd like to see Fedora become more of an "operating system factory".

20s is from 2020 to 2029. 10 years. So long.
So, let me write high level thoughts. And let me post a new topic.

For the topic 'more of an "operating system factory"', I want to see
Fedora project as a place to "democratize new technologies".

Nowadays many people can use the computer and internet with relatively
affordable cost, not depending on a belonging organization or region.
That means those are democratized.
But back to 1960s, 70s, 90s, only a few people who have access to the
specific academia and companies or in specific regions could use those
technologies relatively easier.
For example, someone living near a company could use a computer for
free for only weekend by negotiating the company.

In my experience, in 1999 I was living in the same region with an NGO
working for a backbone network.
And the NGO helped me to put my Linux server in their network for free.
In the age of non-democratized computer and internet, some
organizations helped for the new technologies.

Now there are not democratized digital tools and hardware again.
The history repeats.

I assume people want to use non-x86_64 servers to debug their
application program with affordable cost
I saw it working in upstream projects.

I was asking to use s390x and ppc64le server to debug an application
by sending email on Fedora.
But after 2 weeks, no response. The operation could be improved.
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

When you keep looking at the community using new technologies with
open source, some hardware are necessary.
This tendency could be increased in the 20s.

What resource helps a technology democratized?
This can be a question to know what Fedora does, when you attend an event.

Fedora's theme in 20s can be "democratizing to the access to the new
technologies".
And the actions are

* Enable non-x86_64 servers for users easily with time sharing.
* Enable hardware for users that is necessary to use technology.
  With time sharing? How to do it? It's a challenge.

Regards,
Jun

-- 
Jun | He - His - Him
___
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: Java Dev Group and Fedora Quality

[Robbie Harwood]

tMario Torre  writes:

> On Mon, Jan 27, 2020 at 5:28 PM Robbie Harwood  wrote:
>
>>> You would not expect a GCC devroom to be concerned about the
>>> problems of all packages written in C and C++, so why would Java be
>>> any different?
>>
>> Honestly?  I totally would expect that.  Wouldn't that be better for
>> everyone?
>>
>> Compilers aren't special here: every package that wishes to continue
>> to have users *needs* to care about those users.  Maintenance and
>> features need to be tailored to actual use cases.  Otherwise, it's a
>> waste of time, and just further irritates said users.
>
> That's not the place for such discussions, this is not a problem that
> is general to Java (and wouldn't be general to the C or C++ languages
> in the case of the GCC example above), is specific to Fedora

Java packaging being extremely difficult is not a Fedora-specific
problem.  The modularity effects are, but the packaging has been
known-hard for a very long time in many distros (and even outside a
distro context, it's not fun to work with the Java package managers).

> and even more specific to some of the packages and needs to be
> addressed within the Fedora community. If there are problems that leak
> upstream in terms of patching requirements the maintainers (and
> perhaps the package users) have the duty to carry this work, you can't
> expect the rest of the world to discuss those issues during a
> developer conference dedicated to the programming language and its
> development, even when there is a mild overlap in interest because
> some of the involved people are the same,

I think that the language and its packaging are too intertwined to be
separated like that.  Look at what python does (or any number of other
languages like it such as rust) - package building and dependencies go
through the same body (the PEP system) as everything else in the
language.  It's not left without attempting to be solved.

But I don't think we will come to agreement on this.

> and neither you can draw conclusions on the interests of the Red Hat
> Java leadership based on the schedule alone.

(For what it's worth, I'm not interested in doing that which is why I
trimmed the email the way I did, though I know Nicolas was.)

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
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

Intent to build OpenImageIO 2.1.10.1

[Richard Shaw]

Since we have side tags now it shouldn't be disruptive but still wanted to
give a warning.

Dependent packages seem to be:

blender
luxcorerender
OpenColorIO

Thanks,
Richard
___
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: Java Dev Group and Fedora Quality

[Mario Torre]

On Mon, Jan 27, 2020 at 5:28 PM Robbie Harwood  wrote:

> > You would not expect a GCC devroom to be concerned about the problems
> > of all packages written in C and C++, so why would Java be any
> > different?
>
> Honestly?  I totally would expect that.  Wouldn't that be better for
> everyone?
>
> Compilers aren't special here: every package that wishes to continue to
> have users *needs* to care about those users.  Maintenance and features
> need to be tailored to actual use cases.  Otherwise, it's a waste of
> time, and just further irritates said users.

That's not the place for such discussions, this is not a problem that
is general to Java (and wouldn't be general to the C or C++ languages
in the case of the GCC example above), is specific to Fedora and even
more specific to some of the packages and needs to be addressed within
the Fedora community. If there are problems that leak upstream in
terms of patching requirements the maintainers (and perhaps the
package users) have the duty to carry this work, you can't expect the
rest of the world to discuss those issues during a developer
conference dedicated to the programming language and its development,
even when there is a mild overlap in interest because some of the
involved people are the same, and neither you can draw conclusions on
the interests of the Red Hat Java leadership based on the schedule
alone.

To get back on topic, I don't have the feeling that the java packaging
is so dismantled, and I use java packages from RHEL and Fedora often,
but I do know there's a series of problems with some of the packages,
and I understand from this thread that some of the issues stem from
the decision to use modules (sorry, I don't make the rules here, and
while I also don't understand why modules are such a hot topic I can't
help on the merit). Now, a constructive discussion would go toward
suggestions on how to fix those problems not focus on pointless
deliberation on what or how the Java DevRoom should be run and whether
it should transform into a Fedora Java Packaging DevRoom.

So, what are your suggestions, and what can we do to help?

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
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

How to handle circular build dependencies?

[Markku Korkeala]

Hi,

sorry if this a newbie question, I tried to search this
but did not find good documentation on this problem.

I'm in the process of upgrading the clojure package to
next version, which has new dependencies. These dependencies
require certain clojure version themselves, so it makes a
chicken-and-egg kind of problem. Are there good ways to handle
these kind of circular dependencies?

I know I can update clojure to certain alpha version,
which the new libraries require. Then build those,
and when they are accepted then upgrade the
clojure package, and then upgrade those libraries, etc. But
it is tedious. I'm hoping there would be a better
way :) And also do I have to do that bootstrapping
again when building clojure for example EPEL-8?

Best regards,
Markku

--
Markku
___
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: Java Dev Group and Fedora Quality

[Robbie Harwood]

Andrew Haley  writes:

> On 1/26/20 11:52 AM, Nicolas Mailhot wrote:
>> Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit :
>>> On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:
>>>
 Java has been in a terminal course in Fedora for a year at
 least. You can see how much Red Hat Java leadership cares about the
 situation by consulting next week’s Java dev room schedule. Red Hat
 is co- organisator of this dev room
 https://fosdem.org/2020/schedule/track/free_java/
>>>
>>> Okay, I'll bite. I am part of the Red Hat Java leadership.
>>>
>>> I'm pleased with this year's FOSDEM schedule. People have submitted
>>> a lot of interesting-looking talks, and I expect it'll be a good
>>> day. I take it that you don't approve of this list, but I don't know
>>> what it is you don't like about it.
>>
>> I was just pointing out that devroom schedules reflect the interests
>> and priorities of the people organizing the devroom. And that those
>> interests and priorities do not include Java getting in such a state
>> that all the Fedora maintainers quit, major apps no loner work, and
>> users are migrating elsewhere.
>
> You would not expect a GCC devroom to be concerned about the problems
> of all packages written in C and C++, so why would Java be any
> different?

Honestly?  I totally would expect that.  Wouldn't that be better for
everyone?

Compilers aren't special here: every package that wishes to continue to
have users *needs* to care about those users.  Maintenance and features
need to be tailored to actual use cases.  Otherwise, it's a waste of
time, and just further irritates said users.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
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: Orphaning owncloud and nextcloud

[Michael Cronenworth]

On 1/17/20 11:53 AM, Miro Hrončok wrote:



On 30. 11. 19 2:27, Ivan Chavero wrote:

Yes i'm going to update it to the newest version this weekend

thanks for following up!


Hello Ivan. Could you please have a look? 


@Ivan,

Any update on the status of Nextcloud?
___
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 Mass Rebuild

[Jeff Law]

On Mon, 2020-01-27 at 16:34 +0100, Jakub Jelinek wrote:
> On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote:
> > Hi all,
> > 
> > Per the Fedora 32 schedule[1] we will be starting a mass rebuild for
> > Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the
> > changes:
> > 
> > https://fedoraproject.org/wiki/Changes/GLIBC231
> > https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33
> > https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
> > https://fedoraproject.org/wiki/Changes/golang1.14
> > https://fedoraproject.org/wiki/Changes/GCC10
> > https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0
> > 
> > we will start the mass rebuild on 2020-01-27
> 
> I thought the mass rebuild should be also for
> https://fedoraproject.org/wiki/LTOByDefault
> but the required changes AFAIK haven't landed into redhat-rpm-config yet.
> 
> CCing Jeff on the current state.
After finally starting looking at the LTO vs GDB issues last week, I
think we should defer LTO until F33.  There's just too many GDB
failures when used with LTO that aren't understood yet.

I have asked that the LTO bytecode stripping change get into redhat-
rpm-config immediately though.  We already know some packages have
enabled LTO and we want to make sure they don't leak the LTO bytecodes
into the distro.

jeff
___
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 Mass Rebuild

[Dan Horák]

On Mon, 27 Jan 2020 10:25:50 -0500
Mohan Boddu  wrote:

> Hi all,
> 
> Per the Fedora 32 schedule[1] we will be starting a mass rebuild for
> Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the
> changes:
> 
> https://fedoraproject.org/wiki/Changes/GLIBC231
> https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33
> https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
> https://fedoraproject.org/wiki/Changes/golang1.14
> https://fedoraproject.org/wiki/Changes/GCC10
> https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0

if I see right, then FPC hasn't been bootstrapped for aarch64 and
ppc64le yet


Dan
___
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 Mass Rebuild

[Jakub Jelinek]

On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote:
> Hi all,
> 
> Per the Fedora 32 schedule[1] we will be starting a mass rebuild for
> Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the
> changes:
> 
> https://fedoraproject.org/wiki/Changes/GLIBC231
> https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33
> https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
> https://fedoraproject.org/wiki/Changes/golang1.14
> https://fedoraproject.org/wiki/Changes/GCC10
> https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0
> 
> we will start the mass rebuild on 2020-01-27

I thought the mass rebuild should be also for
https://fedoraproject.org/wiki/LTOByDefault
but the required changes AFAIK haven't landed into redhat-rpm-config yet.

CCing Jeff on the current state.

Jakub
___
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: Java Dev Group and Fedora Quality

[Nicolas Mailhot via devel]

Le 2020-01-27 15:46, Mario Torre a écrit :


You keep ignoring that a large part of the packaged ecosystem comes
from different places and is maintained by different people,


That’s why coordination conferences like the FOSDEM exist.


and not everything is in a state of chaos as you imply


Others described the current state of Java packaging here. If you 
disagree with those descriptions, by all means correct them.


--
Nicolas Mailhot
___
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

Fedora 32 Mass Rebuild

[Mohan Boddu]

Hi all,

Per the Fedora 32 schedule[1] we will be starting a mass rebuild for
Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the
changes:

https://fedoraproject.org/wiki/Changes/GLIBC231
https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33
https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
https://fedoraproject.org/wiki/Changes/golang1.14
https://fedoraproject.org/wiki/Changes/GCC10
https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0

we will start the mass rebuild on 2020-01-27

This is a heads up that it will be done in a side tag and moved over
when completed. We will be running scripts to output failure stats.
please be sure to let releng know if you see any bugs in the reporting.

You can contact releng in #fedora-releng on freenode.

Failures can be seen

https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html

Things still needing rebuilt

https://kojipkgs.fedoraproject.org/mass-rebuild/f32-need-rebuild.html

Regards

Mohan Boddu
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org
___
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: Groovy Build Failing Due to Disappearance of groovy-local

[Fabio Valentini]

On Mon, Jan 27, 2020 at 2:52 PM Bill Chatfield via devel
 wrote:
>
>
>
> On Monday, January 27, 2020, 3:58:07 AM EST, Fabio Valentini 
>  wrote:
> > Depending on what you want to achieve, I think I can give you better "first 
> > package to work on" suggestions :)
>
> Yes, please give me some suggestions. I thought I had found one with few 
> dependencies but looks like it's harder than it appears. Gradle and Groovy 
> will have to be next though. They're pretty critical.

If you want to look at gradle, good luck - it looks like all linux
distributions I looked at have given up on packaging it properly.
Only Arch is providing up-to-date gradle packages, but they're only
bundling up the upstream release binaries, which isn't acceptable for
fedora.

For something easier to start with, I suggest looking at the packages
the stewardship-sig group is maintaining:
https://decathorpe.fedorapeople.org/stewardship-sig.html#maintained-packages

Since almost all other Java packages have disapparated, we're pretty
much taking care of the whole base of the Java stack. But we can only
provide maintenance on a best-effort basis, so it would be great to
have somebody with real-world Java experience look at some of the
packages.

General information, helper scripts and the ticketing system for our
group is hosted here:
https://pagure.io/stewardship-sig/

For example, we have a list of outdated packages here:
https://decathorpe.fedorapeople.org/stewardship-sig-stats.html

There's also a list of Pull Requests that are ready for review:
https://decathorpe.fedorapeople.org/stewardship-sig-prs.html

This spreadsheet has a broad overview of everything, including some
comments on why some updates are blocked:
https://docs.google.com/spreadsheets/d/11RlwsEs-LJgTOrUD1P4LpsvW9icVQrvrU5RFqxUuccY/edit?usp=sharing

Hope this helps.
Fabio

> ___
> 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
___
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: Java Dev Group and Fedora Quality

[Alex Scheel]

- Original Message -
> From: "Tom Seewald" 
> To: devel@lists.fedoraproject.org
> Sent: Sunday, January 26, 2020 12:35:32 PM
> Subject: Re: Java Dev Group and Fedora Quality
> 
> > On Sat, Jan 25, 2020 at 11:07 PM Bill Chatfield via devel
> *snip*
> > True. Nobody cares about Java packages in fedora, not even Red Hat
> > employees. If you look at the members of the Java SIG, a lot of them
> > were (or still are) Red Hat employees. For example, even JBoss /
> > WildFly (a pretty big Java project by Red Hat) was unmaintained and
> > broken, and most of it has now been removed from future fedora
> > releases. I wonder what they are going to do with RHEL 9 - maybe
> > somebody notices their stuff isn't available on fedora anymore.
> 
> Do you happen to know what the Red Hat employees who maintain Java-based
> products use as their desktop OS? RHEL? macOS?

As a Hatter, I'm proud to say that I--and most all of my team--use
Fedora for our work machines. I run F31 without modular repos on all
four of my boxes in my home office.

I work on Dogtag PKI (https://www.dogtagpki.org), a private CA, built
on top of a Tomcat/Java stack.


Responding to the JBoss dismissal: JBoss is its own product and doesn't
have the goal of shipping on Fedora before it ships in its own product.
All of the JBoss packages maintained in Fedora are maintained by the
community (including non-JBoss Red Hatters) who need them in other
packages.

Concretely, if you'd like to see more JBoss packages, join us in the
Stewardship SIG and collaborate to revive the ones you care
about. :-)


- Alex


N.B.: I'd like to thank the Red Hat JVM team for being solid in
their Fedora execution. But they maintain only the JVM, and not
the rest of the Java ecosystem. :-)

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

Zend Framework retired from rawhide

[Remi Collet]

Hi,


FYI all php-zendframework-* packages are now retire from rawhide.


This project is dead

Read:
https://framework.zend.com/blog/2019-04-17-announcing-laminas.html


So, now, all php-laminas-* packages are built and available
including the compatibility layer which allow to use
it the same way than ZF


Great thanks to Robert-André Mauchin for the mass review.


I was initially planing this as a Fedora 33 feature
but some other projects have start to use Laminas...



Remi


P.S. expressive stuff have moved to Mezzio, but was not used
so have also been retired (without replacement)
___
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: Java Dev Group and Fedora Quality

[Mario Torre]

On Mon, Jan 27, 2020 at 3:32 PM Nicolas Mailhot
 wrote:

> When a community driven conference grows to the size and reach of FOSDEM
> yes you can infer quite a lot from its schedule (one could do the same,
> removing the community word, for things where community is not relevant;
> that’s how half the IT press gets written).

The Devroom only runs for barely a day and there's so much stuff to
discuss we can't really cover everything and nobody submitted a talk
about this topic so it wasn't even considered, but next year you are
fully welcomed to submit one if you want.

> > Also, it may help knowing that packaging of Java application and
> > packaging of OpenJDK are different aspects and not necessarily handled
> > by the same people.
>
> “someone else’s problem” is little different from “I don’t care” in my
> book. And so far, no one has been able to identify those mysterious
> someone elses.

You keep ignoring that a large part of the packaged ecosystem comes
from different places and is maintained by different people, and not
everything is in a state of chaos as you imply, and definitely is not
ignored or "someone else's problem".

But, well... I'm not even sure why I keep replying, trolling with
unconstructive sentences won't really bring us anywhere.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
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: Java Dev Group and Fedora Quality

[Nicolas Mailhot via devel]

Le 2020-01-27 15:13, Mario Torre a écrit :

On Sun, Jan 26, 2020 at 12:53 PM Nicolas Mailhot via devel
 wrote:


Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit :
> On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:
>
> > Java has been in a terminal course in Fedora for a year at
> > least. You can see how much Red Hat Java leadership cares about the
> > situation by consulting next week’s Java dev room schedule. Red Hat
> > is co- organisator of this dev room
> > https://fosdem.org/2020/schedule/track/free_java/
>
> Okay, I'll bite. I am part of the Red Hat Java leadership.
>
> I'm pleased with this year's FOSDEM schedule. People have submitted a
> lot of interesting-looking talks, and I expect it'll be a good day. I
> take it that you don't approve of this list, but I don't know what it
> is you don't like about it.

I was just pointing out that devroom schedules reflect the interests
and priorities of the people organizing the devroom. And that those
interests and priorities do not include Java getting in such a state
that all the Fedora maintainers quit, major apps no loner work, and
users are migrating elsewhere.

It’s not for me to approve or disapprove. People can draw their own
conclusions.


Eh!!??

Nicholas, I'm not sure how you infer all this by the schedule of a
Community driven conference!


When a community driven conference grows to the size and reach of FOSDEM 
yes you can infer quite a lot from its schedule (one could do the same, 
removing the community word, for things where community is not relevant; 
that’s how half the IT press gets written).



Also, it may help knowing that packaging of Java application and
packaging of OpenJDK are different aspects and not necessarily handled
by the same people.


“someone else’s problem” is little different from “I don’t care” in my 
book. And so far, no one has been able to identify those mysterious 
someone elses.


--
Nicolas Mailhot
___
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

Fedora rawhide compose report: 20200127.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200126.n.0
NEW: Fedora-Rawhide-20200127.n.0

= SUMMARY =
Added images:6
Dropped images:  1
Added packages:  1
Dropped packages:0
Upgraded packages:   41
Downgraded packages: 0

Size of added packages:  5.20 MiB
Size of dropped packages:0 B
Size of upgraded packages:   507.50 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   49.43 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20200127.n.0.s390x.tar.xz
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20200127.n.0.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200127.n.0.s390x.qcow2
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200127.n.0.s390x.raw.xz
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200127.n.0.s390x.vmdk
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20200127.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20200126.n.0.iso

= ADDED PACKAGES =
Package: vcglib-1.0.1-1.fc32
Summary: Visualization and Computer Graphics Library
RPMs:vcglib vcglib-devel
Size:5.20 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  amiri-fonts-0.112-1.fc32
Old package:  amiri-fonts-0.111-1.fc32
Summary:  A classical Arabic font in Naskh style
RPMs: amiri-fonts amiri-fonts-common amiri-quran-fonts
Size: 779.89 KiB
Size change:  -192.12 KiB
Changelog:
  * Sun Jan 26 2020 Mosaab Alzoubi  - 0.112-1
  - Update to 0.112


Package:  bear-2.4.3-1.fc32
Old package:  bear-2.4.2-1.fc32
Summary:  Tool that generates a compilation database for clang tooling
RPMs: bear
Size: 222.99 KiB
Size change:  1.55 KiB
Changelog:
  * Sun Jan 26 2020 Dan ??erm??k  - 2.4.3-1
  - Bump version to 2.4.3


Package:  blueman-1:2.1.2-1.fc32
Old package:  blueman-1:2.1.1-4.fc32
Summary:  GTK+ Bluetooth Manager
RPMs: blueman
Size: 4.67 MiB
Size change:  -23.30 KiB
Changelog:
  * Fri Jan 24 2020 Artur Iwicki  - 1:2.1.2-1
  - Update to latest upstream release (2.1.2)


Package:  clamav-0.101.5-6.fc32
Old package:  clamav-0.101.5-5.fc32
Summary:  End-user tools for the Clam Antivirus scanner
RPMs: clamav clamav-data clamav-devel clamav-filesystem clamav-lib 
clamav-milter clamav-update clamd
Size: 172.39 MiB
Size change:  -4.09 KiB
Changelog:
  * Sun Jan 26 2020 S??rgio Basto  - 0.101.5-6
  - Fix clamd scriplets on update and add scriplets for clamav-freshclam.service


Package:  direnv-2.21.1-1.fc32
Old package:  direnv-2.20.1-1.fc32
Summary:  Per-directory shell configuration tool
RPMs: direnv golang-github-direnv-devel
Size: 6.83 MiB
Size change:  196.28 KiB
Changelog:
  * Sun Jan 26 2020 Ed Marshall  - 2.21.1-1
  - Update to 2.21.1


Package:  fpc-3.2.0-0.20200122svn44016.1.fc32
Old package:  fpc-3.0.4-8.fc32
Summary:  Free Pascal Compiler
RPMs: fpc fpc-doc fpc-src
Size: 136.25 MiB
Size change:  43.44 MiB
Changelog:
  * Sun Jan 26 2020 Artur Iwicki  - 
3.2.0-0.20200122svn44016.1
  - Update to latest upstream SVN revision
  - Drop r1448 and r38400 patches (backports from upstream)


Package:  freeipa-4.8.4-3.fc32
Old package:  freeipa-4.8.4-2.fc32
Summary:  The Identity, Policy and Audit system
RPMs: freeipa-client freeipa-client-common freeipa-client-samba 
freeipa-common freeipa-python-compat freeipa-server freeipa-server-common 
freeipa-server-dns freeipa-server-trust-ad python3-ipaclient python3-ipalib 
python3-ipaserver python3-ipatests
Size: 7.99 MiB
Size change:  28.02 KiB
Changelog:
  * Sun Jan 26 2020 Alexander Bokovoy  - 4.8.4-3
  - Rebuild against Samba 4.12RC1


Package:  golang-contrib-opencensus-exporter-stackdriver-0.12.8-1.fc32
Old package:  golang-contrib-opencensus-exporter-stackdriver-0.11.0-2.fc31
Summary:  OpenCensus Go exporter for Stackdriver Monitoring and Trace
RPMs: golang-contrib-opencensus-exporter-stackdriver-devel
Size: 66.54 KiB
Size change:  8.64 KiB
Changelog:
  * Sun Dec 29 2019 Robert-Andr?? Mauchin  - 0.12.8-1
  - Update to 0.12.8 (#1742117)


Package:  golang-github-ajstarks-deck-0-0.3.20200126gitb22ec51.fc32
Old package:  golang-github-ajstarks-deck-0-0.2.20190701git3beea55.fc31
Summary:  Slide Decks
RPMs: golang-github-ajstarks-deck golang-github-ajstarks-deck-devel
Size: 30.22 MiB
Size change:  -159.54 KiB
Changelog:
  * Sun Jan 26 2020 Robert-Andr?? Mauchin  - 
0-0.3.20200126gitb22ec51
  - Bump to commit b22ec51b2c1e28a2cdaf016c16a22456e10188df


Package:  golang-github-ajstarks-svgo-0

Re: Java Dev Group and Fedora Quality

[Mario Torre]

On Sun, Jan 26, 2020 at 12:53 PM Nicolas Mailhot via devel
 wrote:
>
> Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit :
> > On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:
> >
> > > Java has been in a terminal course in Fedora for a year at
> > > least. You can see how much Red Hat Java leadership cares about the
> > > situation by consulting next week’s Java dev room schedule. Red Hat
> > > is co- organisator of this dev room
> > > https://fosdem.org/2020/schedule/track/free_java/
> >
> > Okay, I'll bite. I am part of the Red Hat Java leadership.
> >
> > I'm pleased with this year's FOSDEM schedule. People have submitted a
> > lot of interesting-looking talks, and I expect it'll be a good day. I
> > take it that you don't approve of this list, but I don't know what it
> > is you don't like about it.
>
> I was just pointing out that devroom schedules reflect the interests
> and priorities of the people organizing the devroom. And that those
> interests and priorities do not include Java getting in such a state
> that all the Fedora maintainers quit, major apps no loner work, and
> users are migrating elsewhere.
>
> It’s not for me to approve or disapprove. People can draw their own
> conclusions.

Eh!!??

Nicholas, I'm not sure how you infer all this by the schedule of a
Community driven conference!

Also, it may help knowing that packaging of Java application and
packaging of OpenJDK are different aspects and not necessarily handled
by the same people.

Cheers,
Mario

> Regards,
>
> --
> Nicolas Mailhot
> ___
> 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



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
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

Fedora-Rawhide-20200127.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 25/158 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20200126.n.0):

ID: 514051  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/514051

Old failures (same test failed in Fedora-Rawhide-20200126.n.0):

ID: 513979  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/513979
ID: 513980  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/513980
ID: 513981  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/513981
ID: 513987  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/513987
ID: 513988  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/513988
ID: 514003  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/514003
ID: 514007  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/514007
ID: 514011  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/514011
ID: 514012  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/514012
ID: 514013  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/514013
ID: 514029  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/514029
ID: 514034  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/514034
ID: 514035  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/514035
ID: 514037  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/514037
ID: 514041  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/514041
ID: 514046  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/514046
ID: 514056  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/514056
ID: 514057  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/514057
ID: 514060  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/514060
ID: 514065  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/514065
ID: 514082  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/514082
ID: 514109  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/514109
ID: 514118  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/514118
ID: 514119  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/514119
ID: 514124  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/514124

Soft failed openQA tests: 19/158 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20200126.n.0):

ID: 513986  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/513986
ID: 514001  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/514001
ID: 514004  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/514004
ID: 514008  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/514008
ID: 514081  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/514081
ID: 514102  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/514102
ID: 514125  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/514125
ID: 514127  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/514127

Old soft failures (same test soft failed in Fedora-Rawhide-20200126.n.0):

ID: 513969  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/513969
ID: 513970  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/513970
ID: 513972  Test: x86_64 Server-dvd-iso install_default_upload
URL: ht

Re: Java Dev Group and Fedora Quality

[Nicolas Mailhot via devel]

Le 2020-01-27 10:52, Andrew Haley a écrit :


You would not expect a GCC devroom to be concerned about the problems
of all packages written in C and C++, so why would Java be any
different?


I would expect a GCC devroom to be concerned about the problems of all
packages written in C and C++ once it reached the general failure state
that Java exhibits today in Fedora (and, hopefully, before).

Problem children happen in all languages and are not a language issue.
General failure specific to a language is something else entirely. It
does not happen at the individual app level. It happens at the
tooling/culture/general priorities level.


The packaging of programs which depend on Java is somewhat outside
my remit. Having said that, I am interested to discover why Java
packaging in Fedora is particularly dysfunctional.


If you haven’t followed the story there are many people on the list
that can explain you in detail what happened (both the people that
quit Java packaging side, and the people who’ve been trying to keep
the ship from sinking completely since).

To keep the story short, the rift between the expectations of Java
developers and Java tooling and the needs of the people deploying
Java software in Fedora, reached such a level, that people trying
to bridge this rift burnt out one after the other and were not
replaced.

Regards,

--
Nicolas Mailhot
___
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: swap-on-ZRAM by default

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 25, 2020 at 02:52:05PM -0700, Chris Murphy wrote:
> Question and (pre)proposal:
> Can Fedora converge on a single swap-on-ZRAM implementation, and if
> so, which one? Fedora Workstation WG wants to move to swap-on-ZRAM by
> default in Fedora 33, and the working group needs to pick something
> soon.
> 
> I think it should be zram-generator. It's the most lightweight, can be
> included by default distro wide. Without a configuration file, it
> doesn't run. Thus, each edition/spin, and even the install
> environment, can have their own configuration file, to setup it up
> however they want, or not set it up.

Hi Chris,

I agree with the general proposal of enabling zram by default in
Workstation. From what we have seen so far, it helps in some cases,
without making things worse. If if turns out that there are some
unforeseen downsides, we can trivially back out.

As to which implementation should be used: I think zram-generator is a
solid choice, but I can't say much more than that: I simply don't know
enough about the alternatives to make meaningful comparisons.

> I also suspect it's the only one that could be upstreamed to systemd
> proper, and just included like many other generators.

It is "upstream" in the sense that it is under the same umbrella.
There are no plans to move the code to the main repo, because it's in
rust and currently combining meson which is used for systemd proper
with rust and cargo is not very convenient. And the release schedule
of systemd and zram-generator is fully independent, so there isn't any
particular reason to want to merge them.

(I have seen the RFEs you filed. Been too busy with devconf and travel
to handle them, but they're on the todo list.)

Zbyszek
___
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: Groovy Build Failing Due to Disappearance of groovy-local

[Bill Chatfield via devel]

 

On Monday, January 27, 2020, 3:58:07 AM EST, Fabio Valentini 
 wrote:  > Depending on what you want to achieve, I think 
I can give you better "first package to work on" suggestions :)
Yes, please give me some suggestions. I thought I had found one with few 
dependencies but looks like it's harder than it appears. Gradle and Groovy will 
have to be next though. They're pretty critical.
  ___
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: Java Dev Group and Fedora Quality

[Tom Hughes]

On 27/01/2020 12:01, Adam Williamson wrote:


I don't know in detail how apt works, but IIRC (sorry if I'm wrong), in
a previous discussion of this it's been suggested that the difference
is apt doesn't refresh this data unless you explicitly ask it to, while
dnf does automatically refresh it on most operations, depending on a
refresh time specified in the repository configuration (this is several
days for mostly-not-changing repos, but more like a few minutes or
hours for update repos which change frequently).


Yes update (refresh metadata) and upgrade (update packages) are
separate operations with apt.

Even the updates repository has a 6 hour refresh interval in F31 though
so it shouldn't have to refresh every time - the base repository has
a 7 day refresh interval.

A refresh initially only checks the top level repomd.xml though, which
is tiny - it will only carry on and fetch other things if they appear to
have changed.

I wonder if Bill is running dnf as a normal user rather than as root
so that it is using a per-user metadata cache that will have to be
created if it doesn't exist yet. Running as root, even for operations
like list that don't really need it, is generally better as it can
use the shared system cache.

You should be able to use --cacheonly to stop it refreshing, or indeed
use --refresh to force a refresh. Using --cacheonly will also make it
use the system cache even when running as a normal user.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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: Groovy Build Failing Due to Disappearance of groovy-local

[Mikolaj Izdebski]

On Mon, Jan 27, 2020 at 1:08 PM Miro Hrončok  wrote:
>
> On 27. 01. 20 10:34, Mikolaj Izdebski wrote:
> > On Mon, Jan 27, 2020 at 6:04 AM Bill Chatfield via devel
> >  wrote:
> >>
> >> I have chosen a delinquent Java package to work fix. But I need some help 
> >> understanding what's going on. Groovy is failing to build because it 
> >> depends on gradle-local which doesn't exist. But gradle-local did exist at 
> >> one time because groovy was successfully build with it on 2019-07-30. So, 
> >> where did gradle-local go? Why has it disappeared? I guess the important 
> >> question is how can I get it back?
> >
> > Building of "gradle-local" was disabled with a build conditional.
> > Re-enabling it is possible as long as its dependencies are packaged
> > and included in Fedora. To enable it, first make sure that its
> > dependencies (i.e. "gradle" and "xmvn-connector-gradle") are in
> > Fedora, then open a bug against "javapackages-tools" asking me to
> > re-enable "gradle-local".
>
> In other words, you need to add gradle to add gradle-local and you ned to add
> gradle-local to add gradle. This requires something we call bootstrapping and 
> is
> one of the complicated stuff that usually requires package maintainers of all
> relevant packages cooperating very closely.

"gradle" can be built without "gradle-local" if "with bootstrap" bcond is used.

--
Mikolaj Izdebski
___
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: Groovy Build Failing Due to Disappearance of groovy-local

[Miro Hrončok]

On 27. 01. 20 10:34, Mikolaj Izdebski wrote:

On Mon, Jan 27, 2020 at 6:04 AM Bill Chatfield via devel
 wrote:


I have chosen a delinquent Java package to work fix. But I need some help 
understanding what's going on. Groovy is failing to build because it depends on 
gradle-local which doesn't exist. But gradle-local did exist at one time 
because groovy was successfully build with it on 2019-07-30. So, where did 
gradle-local go? Why has it disappeared? I guess the important question is how 
can I get it back?


Building of "gradle-local" was disabled with a build conditional.
Re-enabling it is possible as long as its dependencies are packaged
and included in Fedora. To enable it, first make sure that its
dependencies (i.e. "gradle" and "xmvn-connector-gradle") are in
Fedora, then open a bug against "javapackages-tools" asking me to
re-enable "gradle-local".


In other words, you need to add gradle to add gradle-local and you ned to add 
gradle-local to add gradle. This requires something we call bootstrapping and is 
one of the complicated stuff that usually requires package maintainers of all 
relevant packages cooperating very closely.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Java Dev Group and Fedora Quality

[Adam Williamson]

On Sun, 2020-01-26 at 22:33 +, Bill Chatfield via devel wrote:
> > That's not really fair. DNF is pretty much only the user interface,
> > and everything it's built on top of (hawkey, librepo, libsolv) is
> > implemented in C / C++. And when I think back to using yum, dnf is
> > really fast :)
> 
> When I type "sudo dnf install something" it takes about 10 minutes to
> pull updates from every repository, every time I run dnf. The actual
> install or update proceeds at a reasonable pace. I wouldn't call it
> fast. I could send you a video of this if you'd like. I see this on
> all my machines and I see other people complaining about it too.

It's refreshing the repository metadata, which is mostly a network-
bound operation and has little to do with the efficiency of the code.

I don't know in detail how apt works, but IIRC (sorry if I'm wrong), in
a previous discussion of this it's been suggested that the difference
is apt doesn't refresh this data unless you explicitly ask it to, while
dnf does automatically refresh it on most operations, depending on a
refresh time specified in the repository configuration (this is several
days for mostly-not-changing repos, but more like a few minutes or
hours for update repos which change frequently).

I believe there's been some discussion of ways the size of the metadata
could be reduced, but that is a question of the overall design of the
system, it's not to do with the quality of the code that implements the
design.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
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

Non-responsive maintainer: David Dick (ddick)

[Xavier Bachelot]

Hi,

I've tried to get in touch with David Dick about 
perl-DateTime-Format-RFC3339. The bug was left untouched, even after 
setting need-info flag. I've also tried to reach to him by direct mail.


According to fedora_active_user, last FAS login was on 2019-12-10, but 
he had no activity since 2016-03-03.

He seems to be still active on CPAN though:
https://metacpan.org/author/DDICK

Anyone knows how to contact him ?

Here's the non-responsive maintainer bug :
https://bugzilla.redhat.com/show_bug.cgi?id=1795179

The following bugs are assigned to him:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&email1=ddick%40cpan.org&emailassigned_to1=1&emailtype1=equals&list_id=10796799&query_format=advanced

He is listed as maintainer for the following packages:
https://src.fedoraproject.org/user/ddick/projects

Regards,
Xavier
___
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: Java Dev Group and Fedora Quality

[Andrew Haley]

On 1/26/20 11:52 AM, Nicolas Mailhot wrote:
> Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit :
>> On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:
>>
>>> Java has been in a terminal course in Fedora for a year at
>>> least. You can see how much Red Hat Java leadership cares about the
>>> situation by consulting next week’s Java dev room schedule. Red Hat
>>> is co- organisator of this dev room
>>> https://fosdem.org/2020/schedule/track/free_java/
>>
>> Okay, I'll bite. I am part of the Red Hat Java leadership.
>>
>> I'm pleased with this year's FOSDEM schedule. People have submitted a
>> lot of interesting-looking talks, and I expect it'll be a good day. I
>> take it that you don't approve of this list, but I don't know what it
>> is you don't like about it.
>
> I was just pointing out that devroom schedules reflect the interests
> and priorities of the people organizing the devroom. And that those
> interests and priorities do not include Java getting in such a state
> that all the Fedora maintainers quit, major apps no loner work, and
> users are migrating elsewhere.

You would not expect a GCC devroom to be concerned about the problems
of all packages written in C and C++, so why would Java be any
different? The problems of Fedora Java packaging, while important, are
somewhat disjoint from those of the platform, especially at a
conference which is not even strictly Linux-specific.

> It’s not for me to approve or disapprove.

As far as I can tell from what has been said, the problems being
discussed here relate to packaging and testing. The packaging of
programs which depend on Java is somewhat outside my remit. Having
said that, I am interested to discover why Java packaging in Fedora is
particularly dysfunctional.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
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: Groovy Build Failing Due to Disappearance of groovy-local

[Mikolaj Izdebski]

On Mon, Jan 27, 2020 at 6:04 AM Bill Chatfield via devel
 wrote:
>
> I have chosen a delinquent Java package to work fix. But I need some help 
> understanding what's going on. Groovy is failing to build because it depends 
> on gradle-local which doesn't exist. But gradle-local did exist at one time 
> because groovy was successfully build with it on 2019-07-30. So, where did 
> gradle-local go? Why has it disappeared? I guess the important question is 
> how can I get it back?

Building of "gradle-local" was disabled with a build conditional.
Re-enabling it is possible as long as its dependencies are packaged
and included in Fedora. To enable it, first make sure that its
dependencies (i.e. "gradle" and "xmvn-connector-gradle") are in
Fedora, then open a bug against "javapackages-tools" asking me to
re-enable "gradle-local".

--
Mikolaj Izdebski
___
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: Java Dev Group and Fedora Quality

[Vít Ondruch]

Dne 26. 01. 20 v 23:33 Bill Chatfield via devel napsal(a):
>> You're right. The Java SIG was not organised around an account group,
>> so it does not exist. I don't know why it is that way, but that could
>> easily be fixed - other language interest groups are organised this
>> way, after all (python-sig, go-sig, ruby-sig, etc.).
> I don't really understand what you're saying here. But I'd like to fix it.


Historically, the SIGs were just bunch of people who typically signed up
on Wiki:


https://fedoraproject.org/wiki/SIGs/Java#Members


More modern approach is to use FAS groups:


https://fedoraproject.org/wiki/SIGs/Python#Python_SIG_FAS_group

https://fedoraproject.org/wiki/SIGs/Ruby#Members


There might or might not be advantages to this. Depending on the SIG
organization, it might give you access to all the packages maintained by
the specific SIG.


Vít

___
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: Groovy Build Failing Due to Disappearance of groovy-local

[Vít Ondruch]

Fabio explained the reasoning etc, but if you are asking where to find
some details yourself, then it is git-dist commit log:

https://src.fedoraproject.org/rpms/gradle/c/4a126e8e3380eda7ceda22b18a9d9633bcd8cda8?branch=master

You can see that in the repository is just `dead.package` file now,
which contains the same justification:

https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package

This is outcome of this guideline:

https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life


HTH


Vít


Dne 27. 01. 20 v 6:03 Bill Chatfield via devel napsal(a):
> I have chosen a delinquent Java package to work fix. But I need some
> help understanding what's going on. Groovy is failing to build because
> it depends on gradle-local which doesn't exist. But gradle-local did
> exist at one time because groovy was successfully build with it on
> 2019-07-30. So, where did gradle-local go? Why has it disappeared? I
> guess the important question is how can I get it back?
>
> https://koschei.fedoraproject.org/package/groovy?collection=f31
>
>
> ___
> 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
___
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: Groovy Build Failing Due to Disappearance of groovy-local

[Fabio Valentini]

On Mon, Jan 27, 2020, 06:04 Bill Chatfield via devel <
devel@lists.fedoraproject.org> wrote:

> I have chosen a delinquent Java package to work fix. But I need some help
> understanding what's going on. Groovy is failing to build because it
> depends on gradle-local which doesn't exist. But gradle-local did exist at
> one time because groovy was successfully build with it on 2019-07-30. So,
> where did gradle-local go? Why has it disappeared? I guess the important
> question is how can I get it back?
>
> https://koschei.fedoraproject.org/package/groovy?collection=f31
>

Hi Bill,

I don't know if groovy is a good first package to look at. You're right,
it's now definitely gone and broken because gradle-local is gone - but it
was also outdated and broken before that.

In turn, gradle was removed from fedora because it was really outdated and
had security issues. It failed to build, and it even failed to build itself.

We tried to keep gradle (and groovy) alive, but it was a pretty gnarly
package to begin with, and since we got no help from the previous
maintainers, we couldn't save it.

Depending on what you want to achieve, I think I can give you better "first
package to work on" suggestions :)

Fabio


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

Fedora-Cloud-31-20200127.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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