Re: the sad state of installability tests

[Michal Srb]

Hello,

po 15. 7. 2024 o 10:57 Zbigniew Jędrzejewski-Szmek 
napísal(a):

> On Mon, Jul 15, 2024 at 10:39:37AM +0200, Cristian Le via devel wrote:
> > Hi Zbyszek,
> >
> > On 2024/07/14 20:04, Zbigniew Jędrzejewski-Szmek wrote:
> > > I'm looking for a solution which doesn't just skip the installability
> > > tests altogether.
> >
> > On PRs with zuul or FedoraCI automation, the same instability tests that
> are
> > done for Bodhi are performed. But what would help is to make these tests
> as
> > required to pass unless they are manually waved. Manually that can be
> done
> > by setting `gating.yaml`. There was some discussion on making some of
> these
> > tests as gating by default.
> >
> > Another issue specific to installability is that the issue is often
> further
> > down the stream, particularly with the SELinux test. Definitely these
> need
> > to be tracked down and fixed.
>
> I fully agree. But a test that just does 'dnf install
> rpms-from-update/*.rpm'
> will predicatably fail.
>
> > > A second problem is that when the tests fail, it's just s hard to
> > > find out why they failed.From the bodhi status page, one has to
> > > go to the Jenkins status page, guess that it's useful to look at
> > > Console Output, scroll over a few pages of incomrehensible JSON
> > > gibberish, guess that it's worth clicking on Testing Farm Artifacts
> URL,
> > > click that, scroll pages of output to see
> > > "guest setup failed: Test environment installation failed: Install
> packages".
> >
> > Weird, when the test is finished, you should have only the final
> > testing-farm results page. Here's an example [1]. Maybe in your case it
> > encountered an internal failure?
> >
> > [1]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-57f489c90d
>
> Maybe I'm doing things wrong. I'd be happy to learn.
>
> I do the following:
> 1. Look at the bodhi update page (
> https://bodhi.fedoraproject.org/updates/FEDORA-2024-3aafcac6a8)
> 2. Click on 'Automated Tests'
>(There seems to be no URL for the view. This means that it's always
> and extra click after every page load or reload.)
> 3. I click on one of the pinkish lines, e.g. the first one.
>   (Another usability problem here is that the click open a new page in
>   new tab/window. Why, oh why? I want to use left-click to open a link
>   in the existing tab, and middle-click to open a new tab. The current
>   UI breaks navigation.)
> 4. I switch to the new tab and see
>
> https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-pipeline/job/master/398487/
>
>(BTW, I mentioned unrelated scary-looking warnings in my OP.
>Here:
>  The following steps that have been detected may have insecure
>  interpolation of sensitive variables (click here for an explanation):
>
>  httpRequest: [TESTING_FARM_API_KEY]
>)
> 5. Click on 'Console Output'
> 6. Click on 'Testing Farm Artifacts URL:
> https://artifacts.dev.testing-farm.io/25316385-50d8-42b4-b4c1-3eff059034eb
> '
> 7. Click on 'build installation' (
> https://artifacts.dev.testing-farm.io/25316385-50d8-42b4-b4c1-3eff059034eb/guest-setup-09b7edc6-0b7e-431b-ae68-afac2527fbb1/artifact-installation-09b7edc6-0b7e-431b-ae68-afac2527fbb1
> )
> 8. Click on 60-Install-packages.txt
>
> So 8 steps to get to the actual result…
>

This is not actually the installability test. This is a functional test
where Testing Farm couldn't prepare the machine and thus the actual test
didn't even start.

But it's true that figuring out what went wrong and where is an impossible
task for mere mortals.

Thanks,
Michal


>
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Changes to Bugzilla API key requirements

[Michal Srb]

st 22. 2. 2023 o 17:27 Ben Cotton  napísal(a):

> Yes, as I understand it, this will make abrt difficult to use.
> Historically, we get about 2500 bug reports via abrt per release.
> That's roughly a quarter of reports per release on average. On the
> other hand, we're not particularly good at fixing abrt-reported bugs.
> Here's the resolution (excluding duplicates) of abrt-reported bugs for
> F19–34:
>
> EOL  32675
> ERRATA3565
> INSUFFICIENT_DATA 2965
> CURRENTRELEASE1162
> NOTABUG983
> UPSTREAM   823
> WORKSFORME 680
> WONTFIX529
> CANTFIX461
> NEXTRELEASE423
> RAWHIDE199
>
> That's a ~73% EOL closure rate, compared to roughly 50% for all bugs.
> Depending on which resolutions you include as "fixed", we fix roughly
> 14% of abrt-reported bugs.
>
> I just found out about this change yesterday. I suspect it's a
> security-driven requirement, so I don't know how much room there will
> be for changes. I'll pass this on to the Bugzilla team and see what
> they say.
>

Thanks! Please keep us posted.

Michal


>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: abrt bugzilla integration not working

[Michal Srb]

Hi Samuel,

so 19. 3. 2022 o 23:53 Samuel Sieb  napísal(a):

> I just tried to file an abrt report.  It asked me to create an API key
> for bugzilla, which I did.  But in the end, when it tried to talk to
> bugzilla, it got an error.
>
> Does the abrt plugin need to be updated for the recent bugzilla changes?
>   I have the latest version and there are no pending updates.
>

If you're on F35+, then this is likely a bug. Please open a ticket in
Bugzilla.
If you're on F34, please make sure that you have the latest libreport
(libreport-2.15.2-4.fc34) installed:

$ sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2022-633d3272bb

Thanks,
Michal


>
> --- Running report_Bugzilla ---
> Checking for duplicates
> fatal: Unable to make sense of XML-RPC response from server.  Invalid
> struct for  value.  Invalid value for 'faultCode' member.  Value
> of type STRING supplied where type INT was expected..  Use
> XMLRPC_TRACE_XML to see for yourself
> ('report_Bugzilla' exited with 1)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes

[Michal Srb]

st 9. 2. 2022 o 20:37 Adam Williamson 
napísal(a):

> On Wed, 2022-02-09 at 20:27 +0100, Michal Srb wrote:
> > st 9. 2. 2022 o 19:39 Michael Catanzaro 
> napísal(a):
> >
> > >
> > > Am I right to suspect that ABRT bug reports are going to disappear for
> > > the foreseeable future?
> > >
> >
> > Nope, we are working on a fix.
>
> That's great news, but since AFAICT this fix is not even proposed as a
> PR for upstream libreport yet, we still seem to be cutting things
> rather fine on the timeline.
>
> Per the current timeline, there are 19 days before an attempt to log in
> with username and password will fail and cause your password to be
> invalidated. Is the libreport fix going to be finished, tested, merged,
> released, and an update pushed stable for all distributions that
> include it, all within 19 days?
>

Fingers crossed.


>
> What do we do about the problem Kamil pointed out, that there are
> current Fedora (and RHEL?) installer images out there with current
> libreport baked in, which will offer username/password login for bug
> reporting forever, and we have no way to change that?
>

Yes, that is a problem. Unfortunately I don't see any way to fix Fedora
images that are already out there.

In RHEL, the option to report to Bugzilla should be available only in
pre-release images, i.e. not in GA'ed ones. But this is something we need
to confirm with anaconda.

I think Bugzilla could automatically send emails that would explain the
situation and next steps, if people try to use username+password after the
deadline. Such clarity might help to mitigate the problem a bit.

Thanks,
Michal



> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes

[Michal Srb]

st 9. 2. 2022 o 19:39 Michael Catanzaro  napísal(a):

>
> Am I right to suspect that ABRT bug reports are going to disappear for
> the foreseeable future?
>

Nope, we are working on a fix.

Thanks,
Michal


>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Michal Srb]

Hi folks,

@Matthew Miller  Are you still trying to save Fedora
from packaging the ocean? :)

On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini  wrote:

> On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller 
> wrote:
> >
> > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > > I'm not sure what's the best solution, but I guess the number one
> > > reason to have packages within the Fedora distribution is for a matter
> > > of trust, if this is the case I would argue that a curated list of
> > > maven packages served via a Fedora managed repository would be a
> > > better investment.
> >
> > I'd love to see someone interested in this pursue this idea! I know we
> > talked about it as long ago as... Flock Prague... and probably before.
>
> This approach will buy you *literally nothing* compared to how things
> already work, assuming you don't advocate just redistributing binary
> artifacts / JARs from Maven Central.
>
> Given that assumption, JARs would still need to be built 1) from
> source, in a 2) trusted environment, 3) against trusted dependencies,
> as I don't think any other approach should be acceptable for content
> distributed by the Fedora Project.
>

> But then you're back to *exactly how Fedora packages for Java projects
> already work* - only with the added complication that distributing
> those build artifacts as plain JARs instead of RPMs now makes them
> impossible to consume as dependencies from other RPM builds.
>

I think it would actually make a huge difference.

Unlike RPM repositories, Maven repositories can easily hold multiple
versions of libraries. Once a JAR is built, the resulting bytecode will
work with current and future JVMs. There is no need to mass-rebuild JARs
every 6 months. And there is certainly no need to try to run every single
Java application with a single "system-wide" version of a library.

Fedora could ship just Java applications that would bundle JARs (whatever
version they need) from the Fedora Maven repository. I don't see this as a
problem, as long as it would be possible to track what JARs are bundled in
what application.

Fedora maintainers could then focus on maintaining applications, and not
maintaining a ton of individual libraries that nobody really cares about
that much.

Thanks,
Michal


>
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Triggering fedora-ci tests

[Michal Srb]

Hello,

On Tue, Jul 13, 2021 at 6:07 PM Mark Wielaard  wrote:

> On Tue, 2021-07-13 at 14:52 +0200, Petr Pisar wrote:
> > V Tue, Jul 13, 2021 at 02:27:57PM +0200, Mark Wielaard napsal(a):
> > > Or How do you trigger a fedora-ci.koji-build.tier0.functional run for a
> > > package?
> > >
> >
> > $ bodhi updates trigger-tests UPDATE_ID
>
> Thanks! That worked, the test were run, CI passed and the package was
> added to stable.
>
> Is there are place to see which tests are pending? Or do you just have
> to run trigger-tests after some time if they haven't yet?
>

The information which tests are queued/running should be visible in Bodhi,
once [1] is resolved.

In the meantime, don't hesitate to hit that "Re-trigger tests" button in
Bodhi if you don't see the results there after some time. And if it still
doesn't work, then please open a ticket in [2].

Thanks,
Michal

[1]: https://pagure.io/fedora-infrastructure/issue/8989
[2]: https://pagure.io/fedora-ci/general/




> Cheers,
>
> Mark
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bodhi critpath package updates now gated on openQA results

[Michal Srb]

Hello,

On Fri, May 14, 2021 at 2:19 AM Adam Williamson 
wrote:

> On Thu, 2021-05-13 at 19:29 +, Mattia Verga via devel wrote:
> > > Hey folks!
> > >
> > > Just wanted to flag up that, now the new Bodhi version has been
> > > deployed to production, critpath updates are gated on openQA test
> > > results. If any openQA test for your critpath update failed, the
> > > gating
> > > status will be marked as 'failed' and you will not be able to push
> > > it
> > > stable.
> > >
> > > Waivers can be issued for failed tests where appropriate:
> > >
> > > https://docs.fedoraproject.org/en-US/ci/gating/#_waive
> > >
> > > But in almost all cases a failure indicates either a genuine bug or
> > > an
> > > opportunity to improve the test, so I'd prefer to avoid use of
> > > waivers
> > > where possible. I am trying to keep an eye on all failed tests, but
> > > if
> > > you have a blocked update and you don't understand the failure and
> > > I
> > > haven't yet commented on it, please do poke me and I'll take a
> > > look.
> > >
> > > If a failure looks like some kind of transient issue, several folks
> > > have the power to rerun tests: myself, lruzicka, kparal, tflink,
> > > abokovoy (abbra / ab), pwhalen, and sumantrom. You can ask one of
> > > us to
> > > do it. There have been plans in the past to implement some sort of
> > > rerun request system in Bodhi but no-one's quite had the roundtuits
> > > to
> > > work it out yet; sorry about that.
> >
> > A "re-run tests" button should be displayed in this case if the
> > logged in user has the power to edit the update (commit access or
> > provenpackager). Do you mean that it doesn't work?
>
> I believe that's strictly wired up to Fedora CI. It doesn't do anything
> for openQA.
>


I thought, under the hood, the button is just telling Bodhi to send the
"bodhi.update.status.testing.koji-build-group.build.complete" [1] message
again, so all CI systems listening should trigger? This isn't the case for
openQA?

Thanks,
Michal

[1]:
https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.bodhi.update.status.testing.koji-build-group.build.complete=18000



> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

What’s new in Fedora CI

[Michal Srb]

Hello!

There are some cool new features in Fedora CI that we would like to tell
you about.

First of all, Fedora CI now supports running tests using the new tmt
format. The tmt tool provides better user experience for enabling, creating
and running tests across different environments (e.g. vm, container,
localhost). The same configuration can be used for enabling tests in
Packit, Fedora CI and RHEL CI. See [1] to get a quick start.

This functionality is available for Rawhide and for dist-git pull requests.
The older STI format is, of course, still supported and it takes precedence
over tmt. If you’d want to switch over to tmt, you will need to rename or
delete the tests*.yml files used by STI.

Next there are 3 generic tests that automatically run on all Rawhide
builds. Note not all of them are completely new — you’ve likely seen some
of these tests before. What’s really new is that all these generic tests
run in Testing Farm [2] now. Testing Farm is a new test execution service
that provides an infrastructure that should be much more stable and as a
result, less flakiness overall.

These generic tests are:

   -

   rpmdeplint
   -

   rpminspect
   -

   installability


If you’d want to know more about any of those tests, please check out the
Fedora CI wiki page [3].

And last but not least, here are some real world examples of (potential)
problems that the tests discovered in the recent Rawhide builds:


[rpmdeplint] undeclared file conflicts:

https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpmdeplint-pipeline/job/master/7921/testReport/(root)/tests/

[rpminspect] relaxed permissions:

https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/6461/testReport/junit/(root)/tests/

[installability] package cannot be installed:

https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/installability-pipeline/job/master/5499/testReport/junit/(root)/tests/



All this was a multi-team effort and I'd like to thank everyone who
participated :)


Thanks,

Michal


[1]: https://docs.fedoraproject.org/en-US/ci/tmt/

[2]: https://testing-farm.gitlab.io/api/

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

Re: Re-Launching the Java SIG

[Michal Srb]

Hello,

On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel <
devel@lists.fedoraproject.org> wrote:

> Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
> > On Fri, 15 May 2020 08:02:34 +0200
> > Michal Srb  wrote:
> >
> > An aside, just to clarify for myself.  That means that all Java apps
> > are
> > the equivalent of statically linked, right?  And are related to
> > things
> > like flatpaks and modules?
>
> No, that’s similar to venv everywhere. The language has bytecode-
> sharing objects. Java upstreams just got used not to share those
> executable objects between projects, not to version them properly, not
> to manage their ABI breaks, and to change things in the local copy
> instead of contributing changes to the original project.
>

Well... Java upstreams share their JARs by uploading them to a public Maven
repository (Maven Central most of the time). And in the vast majority of
cases there are also "source-JARs" (containing source code) uploaded
alongside the bytecode JARs. I am simplifying things here a bit, but
basically when Java open source projects want to ship their apps, they
fetch pre-built dependencies from Maven Central, compile their apps, and
bundle everything (app bytecode + pre-built deps) in a tarball. And that's
what they ship.
JARs in Maven Central are always versioned, and people who want to use them
pick specific versions, so no version ranges... (although technically
possible of course) And JARs in Maven Central are immutable, so if you want
to use such pre-built JAR, you pick a specific version for your app and it
will never change.

What you're describing sounds like the 2005-ish way of developing Java
applications :) The Java open source world has evolved since then.


> That’s non-free software open source to its extreme. The code is
> available for a dev to copy and resell at his next work, but everything
> is organised (at the human not technical level) so it’s not possible to
> reuse the bytecode directly without paying someone to copy and fork the
> original code that this bytecode was generated from in the next
> project.
>

I'd like to know more about this if you don't mind. This is definitely not
how open source Java apps are developed.

Thanks,
Michal


>
> The practical effect is technical stagnation and market capture by deep
> pocket companies.
>

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

Re: Re-Launching the Java SIG

[Michal Srb]

On Thu, May 14, 2020 at 2:42 PM Vít Ondruch  wrote:

>
> Dne 14. 05. 20 v 11:53 Michal Srb napsal(a):
>
> Hello,
>
> On Tue, May 12, 2020 at 12:57 PM Felix Schwarz 
> wrote:
>
>>
>> Am 12.05.20 um 12:32 schrieb Ty Young:
>> > Right, I figured it was some Fedora policy and not up to you. I suppose
>> I
>> > should have been more clear there. Sorry for any confusion, it was
>> aimed at
>> > the Fedora project as a whole as this is a Fedora issue.
>>
>> This is not a Fedora issue but a consequence of Fedora's core values. You
>> not
>> agree with it but "building from source" is so fundamental that it does
>> not
>> make sense to even start a discussion about it on fedora-devel.
>>
>> I suggest you read up on the rationale behind that policy (which is why I
>> linked the policy document in the first place).
>>
>
> I agree that building from sources is the right thing to do. However, let
> me play devil's advocate here :)
>
> What makes Java apps different from other language ecosystems is that Java
> apps never share dependencies. There is no concept of "system-wide"
> 3rd-party Java libraries that would be automatically added to classpath
> when JVM starts.
>
>
> And now how is this different to different language ecosystems? All
> languages I have ever worked with has this attitude, more or less. The
> Linux distributions are fighting against this but with various success.
> With Java, Fedora is failing ATM.
>

Since Java apps always ship their dependencies in tarballs, it's like
upstream is pinning down dependencies to specific versions. There is no
room for any version ranges like for example "as long as you have
java-lib>=2.3 on your system, the dependency will be satisfied". Installing
(well, "unpacking") other Java application that requires java-lib>=3.0 will
never break the first app.

Then Fedora comes in and tries not only to run both Java App #1 and Java
App #2 on the same system, ideally with the single version of
java-lib(latest), but also to build both the apps on the same system (the
build system being the 3rd Java app).
I am not saying this is something bad, it's just something completely
unnatural for the Java App ecosystem.
Java developers ship their tested self-contained tarballs which work on
Linux, Mac and Windows. And Linux distributions take those apps and try to
run them with a completely different set of dependencies. I kinda
understand why upstream projects are not always happy about that...

Although you're right that there are plenty of Python projects out there
that straight up tell you to isolate their applications in a virtual
environment when you're pip-installing them from PyPI. It's not all though.
There are still plenty of projects that tell you that as long as you have
python-lib>=2.3 on your machine, you will be fine. This makes Python
packaging so much easier, at least in my opinion. Such Python apps are not
in full control of their dependency chains, they realize that newer
python-lib could introduce some breaking changes and if you open a pull
request with a patch, they are not surprised, they know what the problem is
and why the pull request should be merged. That's what they signed up for
by saying that python-lib>=2.3 is fine.

Thanks,
Michal


> And if the bundling is not happening on language level, then we are back
> to bundling in containers and flatpacks and what not.
>
>
> Vít
>
>
> I realize that this is technically possible to achieve, but that is not
> how people use it. If you want to distribute your Java app, you just bundle
> it with all its dependencies into a beefy tarball and ship it.
> And if Java apps never share dependencies, then developers are not really
> forced to keep up with latest versions of libraries. Nobody can update the
> non-existent system-wide Java library that would break their application.
> They are in control.
>
> Since there is no standard place for shared Java libraries on your laptop,
> how can you use the packaged Java libraries and develop software against
> them? Sure, you can hack it and make it work on your Fedora 32 machine, but
> your custom Makefile is not guaranteed to work on Fedora 31 or later on 33.
> And your colleague that is on CentOS is out of luck of course. And so are
> all your potential external contributors on their MacBooks and Ubuntus.
> What I am trying to say in this paragraph is that shipping (in RPMs) and
> maintaining individual build-only Java libraries is, at least in my
> opinion, questionable.
>
> Fedora and other linux distributions are trying to do the right thing, but
> things like Java apps simply don't fit in. What Java app developers are
> doing may not be the best thing,

Re: Re-Launching the Java SIG

[Michal Srb]

Hello,

On Tue, May 12, 2020 at 12:57 PM Felix Schwarz 
wrote:

>
> Am 12.05.20 um 12:32 schrieb Ty Young:
> > Right, I figured it was some Fedora policy and not up to you. I suppose I
> > should have been more clear there. Sorry for any confusion, it was aimed
> at
> > the Fedora project as a whole as this is a Fedora issue.
>
> This is not a Fedora issue but a consequence of Fedora's core values. You
> not
> agree with it but "building from source" is so fundamental that it does not
> make sense to even start a discussion about it on fedora-devel.
>
> I suggest you read up on the rationale behind that policy (which is why I
> linked the policy document in the first place).
>

I agree that building from sources is the right thing to do. However, let
me play devil's advocate here :)

What makes Java apps different from other language ecosystems is that Java
apps never share dependencies. There is no concept of "system-wide"
3rd-party Java libraries that would be automatically added to classpath
when JVM starts. I realize that this is technically possible to achieve,
but that is not how people use it. If you want to distribute your Java app,
you just bundle it with all its dependencies into a beefy tarball and ship
it.
And if Java apps never share dependencies, then developers are not really
forced to keep up with latest versions of libraries. Nobody can update the
non-existent system-wide Java library that would break their application.
They are in control.

Since there is no standard place for shared Java libraries on your laptop,
how can you use the packaged Java libraries and develop software against
them? Sure, you can hack it and make it work on your Fedora 32 machine, but
your custom Makefile is not guaranteed to work on Fedora 31 or later on 33.
And your colleague that is on CentOS is out of luck of course. And so are
all your potential external contributors on their MacBooks and Ubuntus.
What I am trying to say in this paragraph is that shipping (in RPMs) and
maintaining individual build-only Java libraries is, at least in my
opinion, questionable.

Fedora and other linux distributions are trying to do the right thing, but
things like Java apps simply don't fit in. What Java app developers are
doing may not be the best thing, but it's been like that for ~20 years, and
it seems to be "good enough" for the majority of people involved (well,
developers at least).
Fedora alone is too insignificant to change it I am afraid.

However, with all that being said. I do like "dnf install my-java-app"
better than unpacking some tarballs somewhere.

And finally, here comes the "devil's advocate" part of my email.

* building Java libraries and apps from sources?
  * +1, no doubt about this
* building Java libraries and apps from sources in a controlled and
reproducible environment?
  * yes, please
* building Java libraries and apps from sources from SRPMs?
  * do we really need the RPM overhead here?
* shipping (in RPMs) and maintaining Java libraries that are not runtime
dependencies of Java applications that we want to have in Fedora?
  * nope, why? build such build-only dependencies from sources, make sure
they are OK license-wise, but do not ship them to users (as explained
above, they are not very useful for developers anyway)

We can do license reviews, we can build from sources, but we don't
necessarily have to do all this in RPMs.
We can do all the right things, store (our binary) results in a
language-native way, which would be a Maven repository controlled by Fedora
in this case, and then simply wrap our good binary JARs into RPMs, without
rebuilding them all the time.

Note having such language-native repository full of good and reviewed Java
libraries would mean that developers that care about such things could
actually start using it instead of the official Maven repository. And they
wouldn't be tied to a specific version of Fedora or Linux.

I don't think this would go against the current packaging policy, it just
would be *a ton" of work :)

This email turned out to be way longer than I expected it to be, but Java
packaging is a complicated topic.

Thanks,
Michal


>
> I understand that missing components/features due to the source requirement
> are annoying but Fedora (and other distros) decided to take the "high road"
> here and actually fix stuff instead of shipping whatever upstream came up
> with.
>
> Felix
> ___
> 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 

Re: Orphaning hibernate

[Michal Srb]

On Tue, Feb 4, 2020 at 5:07 PM Neal Gompa  wrote:

> On Tue, Feb 4, 2020 at 10:36 AM Michal Srb  wrote:
> >
> > Hi Bill,
> >
> >
> > On Tue, Feb 4, 2020 at 4:29 PM Bill Chatfield via devel <
> devel@lists.fedoraproject.org> wrote:
> >>
> >> I may take it as soon as I figure out how.
> >>
> >> But, if you're building a Java app, you probably use Maven to build it,
> so Maven is going to download from mavencentral, not the version packaged
> in Fedora. So I'm beginning to wonder how useful the packaged apps are. Am
> I missing something?
> >
> >
> > Packaged Java apps are useful, but packaged libraries (if not used by
> any Java app in the distribution) not so much. Nobody's going to develop
> anything against them. Like you said, developers will fetch what they need
> from Maven Central.
> >
>
> If we don't have packaged libraries, nobody can ship packaged
> applications. And there are definitely cases where people develop
> against packaged Java libraries. I used to work in one such case.
> Nowadays I live primarily in the Python ecosystem, and I can live
> entirely in packaged libraries there too. It'd be nice to have this
> again for Java.
>
>
This is more complicated and it would probably deserve a separate thread :)
Java and Python are completely different ecosystems. And Java ecosystem
(apps/libs) is just inherently unfriendly to Linux distributions. It's not
necessary bad or broken - it's just different.

I am curious: what was the reason to develop against the packaged Java
libraries?

Thanks,
Michal


>
>
> --
> 真実はいつも一つ！/ 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
>
___
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 hibernate

[Michal Srb]

Hi Bill,


On Tue, Feb 4, 2020 at 4:29 PM Bill Chatfield via devel <
devel@lists.fedoraproject.org> wrote:

> I may take it as soon as I figure out how.
>
> But, if you're building a Java app, you probably use Maven to build it, so
> Maven is going to download from mavencentral, not the version packaged in
> Fedora. So I'm beginning to wonder how useful the packaged apps are. Am I
> missing something?
>

Packaged Java apps are useful, but packaged libraries (if not used by any
Java app in the distribution) not so much. Nobody's going to develop
anything against them. Like you said, developers will fetch what they need
from Maven Central.

Thanks,
Michal


>
> On Tuesday, February 4, 2020, 4:25:48 AM EST, Kevin Kofler <
> kevin.kof...@chello.at> wrote:
>
>
> Fabio Valentini wrote:
> > No fedora package depends on hibernate or any of its subpackages. It
> > can be safely removed.
>
> Java on Fedora is in a really really sad state when we do not even carry
> ubiquitous libraries DEVELOPED BY RED HAT! (But no, I am not signing up to
> do the work for Red Hat, also because I do not use the packaged version of
> Hibernate. That packaged Hibernate would be useful to package Java
> applications, but nobody is working on that anymore. Sad.)
>
> Kevin Kofler
> ___
> 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

Orphaning and planning to retire my old Java packages

[Michal Srb]

Hello,

I've orphaned all my Java packages and my plan is to retire them next week,
if no one wants them. There is many of them, but all (except last 2 in the
list) were added to the distribution as dependencies of Jenkins package.

Thanks,
Michal

rpms/jenkins
rpms/jenkins-antisamy-markup-formatter-plugin
rpms/jenkins-ant-plugin
rpms/jenkins-commons-jelly
rpms/jenkins-credentials-plugin
rpms/jenkins-crypto-util
rpms/jenkins-executable-war
rpms/jenkins-external-monitor-job-plugin
rpms/jenkins-extras-memory-monitor
rpms/jenkins-icon-shim
rpms/jenkins-instance-identity
rpms/jenkins-javadoc-plugin
rpms/jenkins-jexl
rpms/jenkins-junit-plugin
rpms/jenkins-ldap-plugin
rpms/jenkins-mailer-plugin
rpms/jenkins-matrix-auth-plugin
rpms/jenkins-matrix-project-plugin
rpms/jenkins-pam-auth-plugin
rpms/jenkins-remoting
rpms/jenkins-script-security-plugin
rpms/jenkins-ssh-cli-auth
rpms/jenkins-sshd
rpms/jenkins-ssh-slaves-plugin
rpms/jenkins-task-reactor
rpms/jenkins-version-number
rpms/jenkins-winstone
rpms/jenkins-xstream
rpms/jmdns
rpms/jruby-maven-plugins
rpms/js-CodeMirror
rpms/js-yui2
rpms/libpam4j
rpms/maven-hpi-plugin
rpms/metainf-services
rpms/owasp-java-html-sanitizer
rpms/robust-http-client
rpms/rubygem-jruby-openssl
rpms/sezpoz
rpms/stapler
rpms/stapler-adjunct-timeline
rpms/trilead-putty-extension
rpms/trilead-ssh2
rpms/localizer
rpms/access-modifier-annotation
rpms/acegisecurity
rpms/akuma
rpms/annotation-indexer
rpms/bridge-method-injector
rpms/bundling-detection-java
rpms/bytecode-compatibility-transformer
rpms/constant-pool-scanner
rpms/groovy-sandbox
rpms/jBCrypt
rpms/apache-mina
rpms/apache-sshd
___
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: Non-responsive maintainer

[Michal Srb]

/me sending the email second time as the first attempt bounced back to me

Hi Greg,

Thanks for bringing this to my attention. The package is, unfortunately,
broken in all supported Fedora releases. The version of the package is the
last stable release from 1.x branch, but upstream is now (and has been for
quite some time) on 2.x. Upgrading it to 2.x wouldn't be easy by any means,
it would require a ton of time (weeks, easily...) that unfortunately I
don't have at the moment and most likely won't have in foreseeable future.

So I am going to do what I should have done a long time ago - I am going to
retire the package.

I will send a separate email that I am orphaning it (and its dependencies)
and if nobody takes it over, I will just retire it in a week or so.

Thanks,
Michal

On Fri, Aug 30, 2019 at 7:45 AM Michal Srb  wrote:

> Hi Greg,
>
> Thanks for bringing this to my attention. The package is, unfortunately,
> broken in all supported Fedora releases. The version of the package is the
> last stable release from 1.x branch, but upstream is now (and has been for
> quite some time) on 2.x. Upgrading it to 2.x wouldn't be easy by any means,
> it would require a ton of time (weeks, easily...) that unfortunately I
> don't have at the moment and most likely won't have in foreseeable future.
>
> So I am going to do what I should have done a long time ago - I am going
> to retire the package.
>
> I will send a separate email that I am orphaning it (and its dependencies)
> and if nobody takes it over, I will just retire it in a week or so.
>
> Thanks,
> Michal
>
> On Thu, Aug 29, 2019 at 7:50 PM Greg Hellings 
> wrote:
>
>> The jenkins pacakge is fearfully out of date and seems unmaintained. Does
>> anyone know how to get in touch with the maintainer(s) of the package?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1560603
>>
>> --Greg
>>
>
___
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: Unexplained build failure?

[Michal Srb]

Hi Sandro,

On 07/20/2016 09:01 PM, Sandro Mani wrote:

Hi

Can anyone explain why this build is failing after creating the src.rpm?

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


See the parent task:
http://koji.fedoraproject.org/koji/taskinfo?taskID=14960409
and click on "Show result":
"BuildError: package twinkle is blocked for tag f25"

Regards,
Michal



I've scanned the logs, but can't find any error messages in them.

Thanks
Sandro

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

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

Re: Orphaning few packages

[Michal Srb]

On 06/01/2016 02:30 PM, gil wrote:



Il 01/06/2016 13:37, Michal Srb ha scritto:

Hello,


Due to lack of time, I am orphaning following packages:


hi
take these



Thank you gil ;)

Michal



 rpms/spring-ldap -- Java library for simplifying LDAP operations (
master f24 f23 f22 )

 rpms/springframework -- Spring Java Application Framework ( master
f24 f23 f22 )

 rpms/springframework-retry -- Abstraction around retrying failed
operations ( master f24 f23 f22 )


Feel free to take them.


Thanks,

Michal

regards
.g

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

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

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

Orphaning few packages

[Michal Srb]

Hello,


Due to lack of time, I am orphaning following packages:

rpms/PyXB -- Python XML Schema Bindings ( master f24 f23 f22 el6 el5 )

rpms/cvsclient -- CVS library for Java ( master f24 f23 f22 )

rpms/rngom -- Java library for parsing RELAX NG grammars ( master f24 
f23 f22 )


 rpms/spring-ldap -- Java library for simplifying LDAP operations ( 
master f24 f23 f22 )


 rpms/springframework -- Spring Java Application Framework ( master f24 
f23 f22 )


 rpms/springframework-retry -- Abstraction around retrying failed 
operations ( master f24 f23 f22 )



Feel free to take them.


Thanks,

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

Re: [fedora-java] Orphaning jasperreports

[Michal Srb]

Hi,

On 06/22/2015 02:56 PM, gil wrote:

HI
I have intention to orphaning/retire jasperreports [1] ,
because it fails build [2] with new batik (1.8)


The fix is simple in this case:
sed -i 
's|org.apache.batik.dom.svg.SAXSVGDocumentFactory|org.apache.batik.anim.dom.SAXSVGDocumentFactory|' 
\

src/net/sf/jasperreports/renderers/BatikRenderer.java

I am willing to help with maintenance of this package.

Michal



and newer release use non free itext 5.x library.

[1] https://admin.fedoraproject.org/pkgdb/package/jasperreports/
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=10098415


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


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

Jenkins Fedora 21 Test Day 2014-09-30

[Michal Srb]

Hi all,

As you probably already know, Jenkins will be in official repositories 
of upcoming Fedora 21. If you're interested in it, please consider 
participating in today's Jenkins test day.


All necessary information should be available on wiki:
https://fedoraproject.org/wiki/Test_Day:2014-09-30_Jenkins

I am looking forward to seeing your bug reports. Thanks in advance.

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

Re: pdftk retired?

[Michal Srb]

On 03/07/2014 01:30 PM, Susi Lehtola wrote:

On Thu, 06 Mar 2014 14:52:27 -0500
Tom Callaway tcall...@redhat.com wrote:

That are the two reasons why I'm not able to support pdftk on
Fedora anymore and was forced to reitred this package. I'm sorry
for nayone who maintaining any package with dependencies on this
package.

This is why pdftk died. We can't include iText5+ because of its
licensing issues.

But isn't it AGPL licensed, which is a free license..?


See here:
https://lists.fedoraproject.org/pipermail/legal/2011-June/001656.html

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

nodejs-semver license change

[Michal Srb]

nodejs-semver (Semantic versioner for npm) changed license in version 
2.x+ from MIT to BSD.


Michal

https://github.com/isaacs/node-semver/commit/aac3fc45dcd512451dd3df7d3b62c518bd2e7646
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maven tycho Plugin and Reproducible Version Qualifiers

[Michal Srb]

On 11/08/2013 08:18 AM, Manuel Faux wrote:

I'm trying to create a package of a maven project. The project uses the
tycho-packaging maven plugin with reproducible version qualifiers.

I am not checking out the git repository of the project, but a tgz
bundle. Therefore tycho cannot do any git operations and fails with the
following error:

[ERROR] Failed to execute goal
org.eclipse.tycho:tycho-packaging-plugin:0.18.1:build-qualifier
(default-build-qualifier) on project org.eclipse.osgi: Execution
default-build-qualifier of goal
org.eclipse.tycho:tycho-packaging-plugin:0.18.1:build-qualifier failed:
One of setGitDir or setWorkTree must be called. - [Help 1]

Does anyone have a suggestion how to ether disable the reproducible
version qualifiers functionality of tycho, or how else to circumvent
this error?

Manuel
I am not familiar with tycho enough, but I would recommend asking this 
question on java-devel mailing list.


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

Re: Orphaning numerous java packages

[Michal Srb]

On 08/06/2013 01:23 PM, Tomas Radej wrote:

Hi,

I was maintaining numerous java packages as my work assignment, which
changed. I am now releasing ownership of most of them. Many of them are
fully co-maintained. The affected packages are:


felix-gogo-parent
felix-gogo-runtime
felix-gogo-shell
ht2html
jaxen - taken
libreadline-java
maven-antrun-plugin - taken
maven-archiver - taken
maven-artifact-resolver - taken
maven-clean-plugin - taken
maven-compiler-plugin - taken
maven-dependency-analyzer - taken
maven-downloader - taken
maven-file-management - taken
maven-filtering - taken
maven-invoker - taken
maven-jar-plugin - taken
maven-osgi - taken
maven-plugin-build-helper - taken
maven-reporting-api
maven-reporting-exec
maven-reporting-impl
maven-repository-builder
maven-script-interpreter - taken
maven-shared-io - taken
maven-shared-jar - taken
maven-shared-utils - taken
maven-toolchains-plugin - taken
maven-verifier - taken

Michal



TR



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

Re: Orphaning numerous java packages

[Michal Srb]

maven-reporting-*
maven-repository-builder

taken.

Michal

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