Re: Orphaned packages that will be retired (and everything will most likely burn)

[François Cami]

On Thu, Feb 28, 2019 at 5:03 PM Alexander Bokovoy  wrote:
>
> On to, 28 helmi 2019, Stephen John Smoogen wrote:
> >On Thu, 28 Feb 2019 at 06:11, Ingo Hoffmann  wrote:
> >>
> >> Hi,
> >>
> >> First time here and concerned Java citizen. Who or how can I contact 
> >> regarding the maven package maintenance? I want to either maintain or 
> >> co-maintain it if there's someone already doing it.
> >>
> >
> >Note there are 2 different maven's. There is maven in a RPM module set
> >which isn't going away. And then there is a non-modular maven set. You
> >might find that the things you need are in the module set. I would
> >also work with the rest of the java packaging team to see what they
> >are doing and why they are doing it.
> >
> >One of the side effects of modules is that people need to work more
> >together on packages to see if their needs can be better organized and
> >grouped together.
> Unfortunately, this forces other packages to go to modules. For example,
> FreeIPA in Fedora doesn't like to be in a module but this change
> (removal of maven, ant, etc) forces our dependency to disappear and the
> only way for us is to be in a module. This doesn't sound good at all.

Said differently, the above mass-orphaning is equivalent to a
unannounced change (
https://fedoraproject.org/wiki/Releases/30/ChangeSet ).
Note that I do not blame the original maintainer's for orphaning: I'm
just stating that if modules are not accepted in buildroots the impact
is worse than any unannounced, self-contained change. This is the
shortcoming that should be addressed.

François

> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Alexander Bokovoy]

On to, 28 helmi 2019, Stephen John Smoogen wrote:

On Thu, 28 Feb 2019 at 06:11, Ingo Hoffmann  wrote:


Hi,

First time here and concerned Java citizen. Who or how can I contact regarding 
the maven package maintenance? I want to either maintain or co-maintain it if 
there's someone already doing it.



Note there are 2 different maven's. There is maven in a RPM module set
which isn't going away. And then there is a non-modular maven set. You
might find that the things you need are in the module set. I would
also work with the rest of the java packaging team to see what they
are doing and why they are doing it.

One of the side effects of modules is that people need to work more
together on packages to see if their needs can be better organized and
grouped together.

Unfortunately, this forces other packages to go to modules. For example,
FreeIPA in Fedora doesn't like to be in a module but this change
(removal of maven, ant, etc) forces our dependency to disappear and the
only way for us is to be in a module. This doesn't sound good at all.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Stephen John Smoogen]

On Thu, 28 Feb 2019 at 06:11, Ingo Hoffmann  wrote:
>
> Hi,
>
> First time here and concerned Java citizen. Who or how can I contact 
> regarding the maven package maintenance? I want to either maintain or 
> co-maintain it if there's someone already doing it.
>

Note there are 2 different maven's. There is maven in a RPM module set
which isn't going away. And then there is a non-modular maven set. You
might find that the things you need are in the module set. I would
also work with the rest of the java packaging team to see what they
are doing and why they are doing it.

One of the side effects of modules is that people need to work more
together on packages to see if their needs can be better organized and
grouped together.


> Regards,
> Ingo
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Ingo Hoffmann]

Hi,

I submitted a ticket to take over the maven package, 
https://pagure.io/releng/issue/8179.

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Ingo Hoffmann]

Hi,

First time here and concerned Java citizen. Who or how can I contact regarding 
the maven package maintenance? I want to either maintain or co-maintain it if 
there's someone already doing it.

Regards,
Ingo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Vít Ondruch]

Dne 20. 02. 19 v 10:02 Till Maas napsal(a):
> On Fri, Feb 15, 2019 at 04:28:17PM +0100, Vít Ondruch wrote:
>> Dne 15. 02. 19 v 14:22 Emmanuel Seyman napsal(a):
>>> * Hans de Goede [15/02/2019 12:09] :
 And automatic scripts really just should hand it over to the first 
 co-maintainer
 in the list.
>>
>> As long as we have no idea if the other maintainers are active, I am
>> strongly against the automation. I've been there. Followed nor
>> responsive policy just to find out later that instead of orphaning the
>> package, next inactive maintainer became owner. Very frustrating 
> The advantage is that this will clean up the co-maintainer list
> eventually.


Orphaned package is eventually retired and co-mainatainer list is
irrelevant then. I can't see your point.


Vít


>
> Kind regards
> Till
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Till Maas]

On Fri, Feb 15, 2019 at 04:28:17PM +0100, Vít Ondruch wrote:
> 
> Dne 15. 02. 19 v 14:22 Emmanuel Seyman napsal(a):
> > * Hans de Goede [15/02/2019 12:09] :
> >> And automatic scripts really just should hand it over to the first 
> >> co-maintainer
> >> in the list.
> 
> 
> As long as we have no idea if the other maintainers are active, I am
> strongly against the automation. I've been there. Followed nor
> responsive policy just to find out later that instead of orphaning the
> package, next inactive maintainer became owner. Very frustrating 

The advantage is that this will clean up the co-maintainer list
eventually.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Jens-Ulrik Petersen]

On Fri, Feb 15, 2019 at 11:30 PM Vít Ondruch  wrote:

> As long as we have no idea if the other maintainers are active, I am
> strongly against the automation. I've been there. Followed nor
> responsive policy just to find out later that instead of orphaning the
> package, next inactive maintainer became owner. Very frustrating 


I think it may depend on the type of package, for some SIGs at least I
think auto-retiring a needed working package is also rather frustrating
since it generates extra work for the SIG to recover that package.

Talking of which I just filed two review requests for ghc-fgl (which I had
untired last year) and ghc-setlocale:

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

which will unbreak xmonad and darcs. :-)

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Miro Hrončok]

On 11. 02. 19 17:57, Miro Hrončok wrote:

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.

See this in your web browser or curl it at:

https://churchyard.fedorapeople.org/orphans-2019-02-11.txt

Please grep it for your username.


I'm on vacation, so I'm not retiring anything at this moment, but here's an 
updated list JFYI:


https://churchyard.fedorapeople.org/orphans-2019-02-18.txt

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Vít Ondruch]

Dne 15. 02. 19 v 14:22 Emmanuel Seyman napsal(a):
> * Hans de Goede [15/02/2019 12:09] :
>> And automatic scripts really just should hand it over to the first 
>> co-maintainer
>> in the list.


As long as we have no idea if the other maintainers are active, I am
strongly against the automation. I've been there. Followed nor
responsive policy just to find out later that instead of orphaning the
package, next inactive maintainer became owner. Very frustrating 


Vít


> This inspires two observations (which I'm sure you already know).
>
> * There's no such thing as "the first co-maintainer"
>
> There are co-maintainers and they all have equal standing. Picking one
> to give the package to is going to require one of:
>   1) asking them to figure it out amongst themselves
>   2) something based on /dev/random
>   3) running 'git shortlog -s | sort -nr' and going down the list
>
> * It's more polite to ask first
>
> Making someone the maintainer should probably require his informed consent.
> A co-maintainer might exist for the sole case of maintaing (perl|python|php)
> bindings of a given application. In this case, making them the point of
> contract will probably not yield the results you're looking for.
>
> Emmanuel
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Emmanuel Seyman]

* Hans de Goede [15/02/2019 12:09] :
>
> And automatic scripts really just should hand it over to the first 
> co-maintainer
> in the list.

This inspires two observations (which I'm sure you already know).

* There's no such thing as "the first co-maintainer"

There are co-maintainers and they all have equal standing. Picking one
to give the package to is going to require one of:
  1) asking them to figure it out amongst themselves
  2) something based on /dev/random
  3) running 'git shortlog -s | sort -nr' and going down the list

* It's more polite to ask first

Making someone the maintainer should probably require his informed consent.
A co-maintainer might exist for the sole case of maintaing (perl|python|php)
bindings of a given application. In this case, making them the point of
contract will probably not yield the results you're looking for.

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Hans de Goede]

Hi,

On 15-02-19 12:51, Mikolaj Izdebski wrote:

On Fri, Feb 15, 2019 at 12:11 PM Hans de Goede  wrote:

I will take sdljava as bolzplatz relies on it.

I do not know how / why this was orphaned. This package has
2 other admin's in the user/group settings. If this was done
automatically it would be nice if we could change the automatic
procedure to just make the next admin the main admin.


sdljava was orphaned by me, the previous owner. The reason is that I
am no longer interested in maintaining this package. I choose to
retain access to the package because I want to have ability to fix
important bugs in already released Fedora versions (28 and 29) without
having to obey the provenpackager policy.


If this was done manually it would be nice if whomever orphaned it
would have instead given it to one of the 2 other admins.


The standard operating procedure is clear - give package to the orphan
user and announce it on devel list so that anyone interested
(including comaintainers) can adopt orphaned package. This is exactly
what I did.


That may be the procedure, but you could have applied common-sense
and ask one of the 2 co-admins if you could give it to them, that
would have short-circuited the need for having to go through releng,
so less work for all people involved.

Anyways as I already said I think the procedure needs to be updated
to explicitly ask the person doing the orphaning to contact co-maintainers
before orphaning if there are co-maintainers.

While brainstorming about improving the procedure I believe it
should also include doing:

sudo dnf repoquery --whatrequires https://pagure.io/fesco/issue/2091

Regards,

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Mikolaj Izdebski]

On Fri, Feb 15, 2019 at 12:11 PM Hans de Goede  wrote:
> I will take sdljava as bolzplatz relies on it.
>
> I do not know how / why this was orphaned. This package has
> 2 other admin's in the user/group settings. If this was done
> automatically it would be nice if we could change the automatic
> procedure to just make the next admin the main admin.

sdljava was orphaned by me, the previous owner. The reason is that I
am no longer interested in maintaining this package. I choose to
retain access to the package because I want to have ability to fix
important bugs in already released Fedora versions (28 and 29) without
having to obey the provenpackager policy.

> If this was done manually it would be nice if whomever orphaned it
> would have instead given it to one of the 2 other admins.

The standard operating procedure is clear - give package to the orphan
user and announce it on devel list so that anyone interested
(including comaintainers) can adopt orphaned package. This is exactly
what I did.

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Dan Čermák]

I'll take over zopfli.

Miro Hrončok  writes:

> 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.
>
> See this in your web browser or curl it at:
>
> https://churchyard.fedorapeople.org/orphans-2019-02-11.txt
>
> Please grep it for your username.
>
>
>  Package  (co)maintainers   Status 
> Change
> 
> OSGi-bundle-ant-task  orphan   1 weeks ago
> RunSnakeRun   orphan   4 weeks ago
> SimplyHTMLmizdebsk, orphan 0 weeks ago
> aether-connector-okhttp   galileo, mizdebsk, orphan0 weeks ago
> ant   akurtakov, jcapik, kdaniel,  0 weeks ago
>mizdebsk, msrb, orphan
> ant-antunit   mizdebsk, orion, orphan  0 weeks ago
> ant-contrib   davidcl, mizdebsk, orphan0 weeks ago
> antlr3dchen, lef, mizdebsk,0 weeks ago
>mjakubicek, orphan, walters
> antlr4gil, jkastner, lef, mizdebsk,0 weeks ago
>orphan
> aopalliance   mizdebsk, orphan 0 weeks ago
> apache-commons-beanutils  fnasser, mizdebsk, orphan,   0 weeks ago
>spike
> apache-commons-collectionsjcapik, mizdebsk, orphan 0 weeks ago
> apache-commons-collections4   mizdebsk, orphan 0 weeks ago
> apache-commons-compress   mizdebsk, mkoncek, orphan,   0 weeks ago
>spike
> apache-commons-configuration  fnasser, mizdebsk, orphan,   0 weeks ago
>spike
> apache-commons-csvlef, mizdebsk, orphan, spike 0 weeks ago
> apache-commons-daemon mizdebsk, orphan, spike  0 weeks ago
> apache-commons-discovery  lkundrak, mizdebsk, orphan,  0 weeks ago
>spike
> apache-commons-el fnasser, mizdebsk, orphan,   0 weeks ago
>spike
> apache-commons-fileupload jerboaa, mizdebsk, mmraka,   0 weeks ago
>orphan, spike
> apache-commons-io mizdebsk, orphan, spike  0 weeks ago
> apache-commons-jexl   mizdebsk, orphan 0 weeks ago
> apache-commons-jxpath fnasser, mizdebsk, orphan,   0 weeks ago
>spike
> apache-commons-lang   mizdebsk, orphan, spike  0 weeks ago
> apache-commons-lang3  mizdebsk, orphan 0 weeks ago
> apache-commons-loggingkdaniel, mizdebsk, orphan,   0 weeks ago
>spike
> apache-commons-netmizdebsk, orphan, spike  0 weeks ago
> apache-ivymizdebsk, orphan 0 weeks ago
> apache-james-project  lef, mizdebsk, orphan0 weeks ago
> apache-logging-parent mizdebsk, orphan 0 weeks ago
> apache-mime4j lef, mizdebsk, orphan0 weeks ago
> apache-parent mizdebsk, orphan 0 weeks ago
> apache-ratmizdebsk, orphan 0 weeks ago
> apache-resource-bundles   mizdebsk, orphan 0 weeks ago
> apiguardian   mizdebsk, orphan 0 weeks ago
> aqute-bnd jcapik, mizdebsk, orphan 0 weeks ago
> args4jjcapik, mizdebsk, orphan 0 weeks ago
> atinject  kdaniel, mizdebsk, orphan0 weeks ago
> autotrash frafra, orphan, robyduck 6 weeks ago
> avalon-framework  jerboaa, mizdebsk, orphan0 weeks ago
> avalon-logkit jerboaa, mizdebsk, orphan0 weeks ago
> base64coder   jcapik, mizdebsk, orphan 0 weeks ago
> batik jvanek, mizdebsk, orphan 0 weeks ago
> bcel 

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Paolo Bonzini]

On 13/02/19 14:31, Richard W.M. Jones wrote:
> Isn't the assembler syntax different or does gas now support
> the nasm syntax (and macros plus a bunch of other stuff AIUI)?
> If we require gas then I assume a whole bunch of asm would have
> to be rewritten ...

Indeed, for example edk2 used to have separate source files for masm and
gas (yuck) and has standardized on nasm a few years ago.  If binutils
can support nasm syntax, I'd be happy to use it of course.

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Richard W.M. Jones]

On Wed, Feb 13, 2019 at 11:30:43AM +, Nick Clifton wrote:
> Hi Paolo,
> 
> > I can maintain nasm if no one else wants to take it.
> 
> Please do, if that it what you want.  However I think that it
> might be better in the long run if we can retire nasm (and yasm
> too) and instead replace them with gas.  

Isn't the assembler syntax different or does gas now support
the nasm syntax (and macros plus a bunch of other stuff AIUI)?
If we require gas then I assume a whole bunch of asm would have
to be rewritten ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 13 February 2019 at 12:30, Nick Clifton wrote:
> Hi Paolo,
> 
> > I can maintain nasm if no one else wants to take it.
> 
> Please do, if that it what you want.  However I think that it
> might be better in the long run if we can retire nasm (and yasm
> too) and instead replace them with gas.  

Tell that to the numerous upstreams who rely on nasm.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Nick Clifton]

Hi Paolo,

> I can maintain nasm if no one else wants to take it.

Please do, if that it what you want.  However I think that it
might be better in the long run if we can retire nasm (and yasm
too) and instead replace them with gas.  

Cheers
  Nick

PS.  In case there is someone reading this email who is unfamiliar
with gas, it is the GNU assembler from the binutils package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Dominik 'Rathann' Mierzejewski]

On Monday, 11 February 2019 at 18:12, Paolo Bonzini wrote:
> On 11/02/19 17:57, Miro Hrončok wrote:
> > 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.
> > 
> > See this in your web browser or curl it at:
> > 
> > https://churchyard.fedorapeople.org/orphans-2019-02-11.txt
> > 
> > Please grep it for your username.
> 
> I can maintain nasm if no one else wants to take it.

Me too. It's required by many multimedia packages, some of which I
maintain here and in RPM Fusion.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Nicolas Mailhot]

Le 2019-02-12 11:43, Adam Samalik a écrit :


I might be missing something here, so excuse me if that's obvious, but
wouldn't this happen without Modularity anyway? I mean, how does
Modularity relate to packages being orphaned? Or is that because they
have been moved out into modules and their maintainers stopped
building them for Everything?


Yes

The main Fedora maintainer mass-orphaned dozens of core java packages to 
move his activity into a module.


So pretty much any package that needs a java stack in Fedora in DOA now

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Igor Gnatenko]

It won't help because you didn't take the build dependencies of ant/maven…

On Tue, Feb 12, 2019 at 12:51 PM Fabio Valentini 
wrote:

> On Tue, Feb 12, 2019 at 12:16 PM Fabio Valentini 
> wrote:
> >
> > On Tue, Feb 12, 2019 at 12:08 PM Miro Hrončok 
> wrote:
> > >
> > > On 12. 02. 19 11:46, Fabio Valentini wrote:
> > > >> (I know anyone can unbreak it by claiming the packages, but that's
> not the point
> > > >> here.)
> > > >
> > > > Miro, am I reading it correctly that the list below "Orphans
> (rawhide)
> > > > (not depended on) (147):" is the list of orphan leaf packages?
> > >
> > > Yes.
> > >
> > > > Also, if somebody can help me come up with a minimal set of "critical
> > > > link" packages that need to be taken care of, that would be very much
> > > > appreciated. I'll then request maintainership for those, unless I
> come
> > > > to my senses by then.
> > >
> > > Search for "Depending on: ", it shall give you hints like:
> > >
> > >Depending on: ant (310)
> > >
> > > or
> > >
> > >Depending on: apache-commons-discovery (2)
> > >
> > >
> > > => ant is more important than apache-commons-discovery.
> > >
> > > This gives you ultimate dependencies, so for example libreoffice is
> counted in
> > > nasm (290) because it requires libjpeg.so.62 and libjpeg-turbo
> requires nasm.
> >
> > Thanks! That's exactly what I meant.
>
> I've now submitted an unorphan request for the following packages:
>
> ant
> antlr3
> antlr4
> bcel
> bsh
> jetty
> maven
> xz-java
> zopfli
>
> nasm is already taken care of as well.
>
> I guess next week's report will show if I / we missed any other
> important packages.
>
> > Fabio
> >
> > > --
> > > 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://getfedora.org/code-of-conduct.html
> > > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Tom Hughes]

On 12/02/2019 11:46, Mikolaj Izdebski wrote:

On Tue, Feb 12, 2019 at 11:56 AM Tom Hughes  wrote:

Java and everything java related (like ant) is now modular only
and has been orphaned in the non-modular rawhide.


That's totally not true. There are about 1.4k source Java packages,
but there are less that 200 modular Java source packages. Notably,
OpenJDK, Tomcat, Eclipse, Wildfly, Jenkins packages are not modular.
Moreover, all modular Java packages also have non-modular versions.
Only 260 out of ~1.4 Java packages are orphaned. Other packages still
have owners.


Apologies if I got it wrong - that as based on my memory of an
announcement from some time ago combined with key components like
any having been orphaned.

On the other hand while it may currently be true that all modular
java packages have non-modular versions that won't be true in a
few weeks when this round of retirements happen right? At least
unless somebody picks up the orphans as I see has now happened
for some key things.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Mikolaj Izdebski]

On Tue, Feb 12, 2019 at 11:56 AM Tom Hughes  wrote:
> Java and everything java related (like ant) is now modular only
> and has been orphaned in the non-modular rawhide.

That's totally not true. There are about 1.4k source Java packages,
but there are less that 200 modular Java source packages. Notably,
OpenJDK, Tomcat, Eclipse, Wildfly, Jenkins packages are not modular.
Moreover, all modular Java packages also have non-modular versions.
Only 260 out of ~1.4 Java packages are orphaned. Other packages still
have owners.

--
Mikolaj Izdebski


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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Fabio Valentini]

On Tue, Feb 12, 2019 at 12:16 PM Fabio Valentini  wrote:
>
> On Tue, Feb 12, 2019 at 12:08 PM Miro Hrončok  wrote:
> >
> > On 12. 02. 19 11:46, Fabio Valentini wrote:
> > >> (I know anyone can unbreak it by claiming the packages, but that's not 
> > >> the point
> > >> here.)
> > >
> > > Miro, am I reading it correctly that the list below "Orphans (rawhide)
> > > (not depended on) (147):" is the list of orphan leaf packages?
> >
> > Yes.
> >
> > > Also, if somebody can help me come up with a minimal set of "critical
> > > link" packages that need to be taken care of, that would be very much
> > > appreciated. I'll then request maintainership for those, unless I come
> > > to my senses by then.
> >
> > Search for "Depending on: ", it shall give you hints like:
> >
> >Depending on: ant (310)
> >
> > or
> >
> >Depending on: apache-commons-discovery (2)
> >
> >
> > => ant is more important than apache-commons-discovery.
> >
> > This gives you ultimate dependencies, so for example libreoffice is counted 
> > in
> > nasm (290) because it requires libjpeg.so.62 and libjpeg-turbo requires 
> > nasm.
>
> Thanks! That's exactly what I meant.

I've now submitted an unorphan request for the following packages:

ant
antlr3
antlr4
bcel
bsh
jetty
maven
xz-java
zopfli

nasm is already taken care of as well.

I guess next week's report will show if I / we missed any other
important packages.

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Fabio Valentini]

On Tue, Feb 12, 2019 at 12:08 PM Miro Hrončok  wrote:
>
> On 12. 02. 19 11:46, Fabio Valentini wrote:
> >> (I know anyone can unbreak it by claiming the packages, but that's not the 
> >> point
> >> here.)
> >
> > Miro, am I reading it correctly that the list below "Orphans (rawhide)
> > (not depended on) (147):" is the list of orphan leaf packages?
>
> Yes.
>
> > Also, if somebody can help me come up with a minimal set of "critical
> > link" packages that need to be taken care of, that would be very much
> > appreciated. I'll then request maintainership for those, unless I come
> > to my senses by then.
>
> Search for "Depending on: ", it shall give you hints like:
>
>Depending on: ant (310)
>
> or
>
>Depending on: apache-commons-discovery (2)
>
>
> => ant is more important than apache-commons-discovery.
>
> This gives you ultimate dependencies, so for example libreoffice is counted in
> nasm (290) because it requires libjpeg.so.62 and libjpeg-turbo requires nasm.

Thanks! That's exactly what I meant.

Fabio

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Adam Samalik]

On Tue, Feb 12, 2019 at 11:54 AM Tom Hughes  wrote:

> On 12/02/2019 10:43, Adam Samalik wrote:
>
> > I might be missing something here, so excuse me if that's obvious, but
> > wouldn't this happen without Modularity anyway? I mean, how does
> > Modularity relate to packages being orphaned? Or is that because they
> > have been moved out into modules and their maintainers stopped building
> > them for Everything?
>
> I believe that is exactly what is happening.
>
> Java and everything java related (like ant) is now modular only
> and has been orphaned in the non-modular rawhide.
>

Petr, Stephen, I'm wondering how fast we're able to deliver the "default
module streams in the traditional buildroot" functionality for infra
builds? Could even we make it on time to make ^^ work?


> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>


-- 

Adam Šamalík
---
Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Miro Hrončok]

On 12. 02. 19 11:46, Fabio Valentini wrote:

(I know anyone can unbreak it by claiming the packages, but that's not the point
here.)


Miro, am I reading it correctly that the list below "Orphans (rawhide)
(not depended on) (147):" is the list of orphan leaf packages?


Yes.


Also, if somebody can help me come up with a minimal set of "critical
link" packages that need to be taken care of, that would be very much
appreciated. I'll then request maintainership for those, unless I come
to my senses by then.


Search for "Depending on: ", it shall give you hints like:

  Depending on: ant (310)

or

  Depending on: apache-commons-discovery (2)


=> ant is more important than apache-commons-discovery.

This gives you ultimate dependencies, so for example libreoffice is counted in 
nasm (290) because it requires libjpeg.so.62 and libjpeg-turbo requires nasm.


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Tom Hughes]

On 12/02/2019 10:43, Adam Samalik wrote:

I might be missing something here, so excuse me if that's obvious, but 
wouldn't this happen without Modularity anyway? I mean, how does 
Modularity relate to packages being orphaned? Or is that because they 
have been moved out into modules and their maintainers stopped building 
them for Everything?


I believe that is exactly what is happening.

Java and everything java related (like ant) is now modular only
and has been orphaned in the non-modular rawhide.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Miro Hrončok]

On 12. 02. 19 11:43, Adam Samalik wrote:> (I know anyone can unbreak it by 
claiming the packages, but that's not the

point
here.)


I might be missing something here, so excuse me if that's obvious, but wouldn't 
this happen without Modularity anyway? I mean, how does Modularity relate to 
packages being orphaned? Or is that because they have been moved out into 
modules and their maintainers stopped building them for Everything?


If a maintainer decided to orphan hundreds of packages at once, some of them 
crucial, this would happen. But here, the maintainer decided to do so because he 
want to maintain them in modules only.


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Fabio Valentini]

On Tue, Feb 12, 2019 at 11:03 AM Miro Hrončok  wrote:
>
> On 12. 02. 19 10:47, Brian (bex) Exelbierd wrote:
> >
> >
> > On Tue, Feb 12, 2019 at 10:17 AM Tom Hughes  > > wrote:
> >
> > So basically the module squad have managed to ensure that everything
> > that relies on ant to build is going to have to modularise or else be
> > forced out of the distribution then...
> >
> > Fortunately that only includes one thing of mine and that's just some
> > java bindings that I can drop but forcing libreoffice out of Fedora on
> > the hill of modularisation will certainly be an achievement of sorts.
> >
> >
> > They say the easiest way to learn the right answer is to post the wrong 
> > answer
> > on the internet. Here is my “wrong” answer that I hope someone will correct 
> > so
> > my context on this thread is correct.
> >
> > As a user who wants to run a piece of software:
> >
> > * I can run software like LibreOffice in a flatpak that works like a 
> > container
> > (not identically) and I can get it via a dnf-like command line tool or the 
> > GUI
> > software store. When I run the app I can’t tell it is in a flatpak. If the 
> > app
> > isn’t graphical I can generally achieve the same effect with a container and
> > some knowledge of container runtime configuration.
> >
> > * I can enable a module that provides the software using a dnf command. At 
> > that
> > point the dnf command installs the software as though it was in the 
> > “everything”
> > repo. Once the enable command is run I can’t tell that the software is 
> > delivered
> > as a module.
> >
> > As a developer who relies on a dependency that is module only:
> >
> > * I can build in containers and on my local machine by enabling the module. 
> > This
> > causes dnf and dependency installs to work as though the contents of the 
> > module
> > were in the “everything” repo.
> >
> > * Today, I cannot build packages for the “everything” repo that have 
> > runtime or
> > build dependencies on modules. Work is being done to allow build 
> > dependencies
> > that are in a module to be used.
> >
> > Overall, as a user, to a large degree, the delivery mechanism (rpm,
> > container/flatpak, and module) doesn’t affect me, except briefly at install.
> >
> > Overall, as a developer, today if my dependencies are modules, I have to 
> > build a
> > module. Tomorrow if my runtime dependencies are modules I have to build a
>
> (anchor)
>
> > module, but otherwise I can build an “everything” repo rpm. I can deliver 
> > via
> > container or flatpak today no matter what.
> >
> > As a system administrator, if my machines have internet access I may have to
> > learn a few new commands, but it all works. If my machines are getting their
> > software indirectly, my experience will vary based on whether my indirection
> > server can handle modules, flatpaks and containers.
> >
> > Is this close to right?
> Pretty much, with one subtle difference.
>
> It' not tomorrow (see: anchor). It's in undefined future. And we are breaking
> things now, before that future comes. Not for the first time.
>
> (I know anyone can unbreak it by claiming the packages, but that's not the 
> point
> here.)

Miro, am I reading it correctly that the list below "Orphans (rawhide)
(not depended on) (147):" is the list of orphan leaf packages?

Also, if somebody can help me come up with a minimal set of "critical
link" packages that need to be taken care of, that would be very much
appreciated. I'll then request maintainership for those, unless I come
to my senses by then.

Fabio

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Adam Samalik]

On Tue, Feb 12, 2019 at 11:03 AM Miro Hrončok  wrote:

> On 12. 02. 19 10:47, Brian (bex) Exelbierd wrote:
> >
> >
> > On Tue, Feb 12, 2019 at 10:17 AM Tom Hughes  > > wrote:
> >
> > So basically the module squad have managed to ensure that everything
> > that relies on ant to build is going to have to modularise or else be
> > forced out of the distribution then...
> >
> > Fortunately that only includes one thing of mine and that's just some
> > java bindings that I can drop but forcing libreoffice out of Fedora
> on
> > the hill of modularisation will certainly be an achievement of sorts.
> >
> >
> > They say the easiest way to learn the right answer is to post the wrong
> answer
> > on the internet. Here is my “wrong” answer that I hope someone will
> correct so
> > my context on this thread is correct.
> >
> > As a user who wants to run a piece of software:
> >
> > * I can run software like LibreOffice in a flatpak that works like a
> container
> > (not identically) and I can get it via a dnf-like command line tool or
> the GUI
> > software store. When I run the app I can’t tell it is in a flatpak. If
> the app
> > isn’t graphical I can generally achieve the same effect with a container
> and
> > some knowledge of container runtime configuration.
> >
> > * I can enable a module that provides the software using a dnf command.
> At that
> > point the dnf command installs the software as though it was in the
> “everything”
> > repo. Once the enable command is run I can’t tell that the software is
> delivered
> > as a module.
> >
> > As a developer who relies on a dependency that is module only:
> >
> > * I can build in containers and on my local machine by enabling the
> module. This
> > causes dnf and dependency installs to work as though the contents of the
> module
> > were in the “everything” repo.
> >
> > * Today, I cannot build packages for the “everything” repo that have
> runtime or
> > build dependencies on modules. Work is being done to allow build
> dependencies
> > that are in a module to be used.
> >
> > Overall, as a user, to a large degree, the delivery mechanism (rpm,
> > container/flatpak, and module) doesn’t affect me, except briefly at
> install.
> >
> > Overall, as a developer, today if my dependencies are modules, I have to
> build a
> > module. Tomorrow if my runtime dependencies are modules I have to build
> a
>
> (anchor)
>
> > module, but otherwise I can build an “everything” repo rpm. I can
> deliver via
> > container or flatpak today no matter what.
> >
> > As a system administrator, if my machines have internet access I may
> have to
> > learn a few new commands, but it all works. If my machines are getting
> their
> > software indirectly, my experience will vary based on whether my
> indirection
> > server can handle modules, flatpaks and containers.
> >
> > Is this close to right?
> Pretty much, with one subtle difference.
>
> It' not tomorrow (see: anchor). It's in undefined future. And we are
> breaking
> things now, before that future comes. Not for the first time.
>

I believe that we do not allow things to break because of packages being
completely moved out into modules. See the nodejs in f29 example: even
though we have a nodejs:10 module, there are still nodejs 10 packages in
the Everything so they are available in the buildroot. Once we fix the
problem and add default module streams to the buildroot, we can set the
nodejs:10 module as a default and remove the traditional packages from the
Everything repo.

Please note that for local builds that's already functional. The only thing
you need to do is to add the Modular repo to your mock config. (We haven't
done that by default as it wouldn't be consistent with the infra builds.)
The Modularity Team is now working on enabling that in the infra. People
might have seen discussions around something called "ursa-major" that could
to that, but it wasn't a very popular solution, so we're working on an
alternative. But this is a priority.


> (I know anyone can unbreak it by claiming the packages, but that's not the
> point
> here.)
>

I might be missing something here, so excuse me if that's obvious, but
wouldn't this happen without Modularity anyway? I mean, how does Modularity
relate to packages being orphaned? Or is that because they have been moved
out into modules and their maintainers stopped building them for Everything?


> --
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Software Engineer
Red Hat

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Miro Hrončok]

On 12. 02. 19 10:47, Brian (bex) Exelbierd wrote:



On Tue, Feb 12, 2019 at 10:17 AM Tom Hughes > wrote:


So basically the module squad have managed to ensure that everything
that relies on ant to build is going to have to modularise or else be
forced out of the distribution then...

Fortunately that only includes one thing of mine and that's just some
java bindings that I can drop but forcing libreoffice out of Fedora on
the hill of modularisation will certainly be an achievement of sorts.


They say the easiest way to learn the right answer is to post the wrong answer 
on the internet. Here is my “wrong” answer that I hope someone will correct so 
my context on this thread is correct.


As a user who wants to run a piece of software:

* I can run software like LibreOffice in a flatpak that works like a container 
(not identically) and I can get it via a dnf-like command line tool or the GUI 
software store. When I run the app I can’t tell it is in a flatpak. If the app 
isn’t graphical I can generally achieve the same effect with a container and 
some knowledge of container runtime configuration.


* I can enable a module that provides the software using a dnf command. At that 
point the dnf command installs the software as though it was in the “everything” 
repo. Once the enable command is run I can’t tell that the software is delivered 
as a module.


As a developer who relies on a dependency that is module only:

* I can build in containers and on my local machine by enabling the module. This 
causes dnf and dependency installs to work as though the contents of the module 
were in the “everything” repo.


* Today, I cannot build packages for the “everything” repo that have runtime or 
build dependencies on modules. Work is being done to allow build dependencies 
that are in a module to be used.


Overall, as a user, to a large degree, the delivery mechanism (rpm, 
container/flatpak, and module) doesn’t affect me, except briefly at install.


Overall, as a developer, today if my dependencies are modules, I have to build a 
module. Tomorrow if my runtime dependencies are modules I have to build a 


(anchor)

module, but otherwise I can build an “everything” repo rpm. I can deliver via 
container or flatpak today no matter what.


As a system administrator, if my machines have internet access I may have to 
learn a few new commands, but it all works. If my machines are getting their 
software indirectly, my experience will vary based on whether my indirection 
server can handle modules, flatpaks and containers.


Is this close to right?

Pretty much, with one subtle difference.

It' not tomorrow (see: anchor). It's in undefined future. And we are breaking 
things now, before that future comes. Not for the first time.


(I know anyone can unbreak it by claiming the packages, but that's not the point 
here.)


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Brian (bex) Exelbierd]

On Tue, Feb 12, 2019 at 10:17 AM Tom Hughes  wrote:

> So basically the module squad have managed to ensure that everything
> that relies on ant to build is going to have to modularise or else be
> forced out of the distribution then...
>
> Fortunately that only includes one thing of mine and that's just some
> java bindings that I can drop but forcing libreoffice out of Fedora on
> the hill of modularisation will certainly be an achievement of sorts.


They say the easiest way to learn the right answer is to post the wrong
answer on the internet. Here is my “wrong” answer that I hope someone will
correct so my context on this thread is correct.

As a user who wants to run a piece of software:

* I can run software like LibreOffice in a flatpak that works like a
container (not identically) and I can get it via a dnf-like command line
tool or the GUI software store. When I run the app I can’t tell it is in a
flatpak. If the app isn’t graphical I can generally achieve the same effect
with a container and some knowledge of container runtime configuration.

* I can enable a module that provides the software using a dnf command. At
that point the dnf command installs the software as though it was in the
“everything” repo. Once the enable command is run I can’t tell that the
software is delivered as a module.

As a developer who relies on a dependency that is module only:

* I can build in containers and on my local machine by enabling the module.
This causes dnf and dependency installs to work as though the contents of
the module were in the “everything” repo.

* Today, I cannot build packages for the “everything” repo that have
runtime or build dependencies on modules. Work is being done to allow build
dependencies that are in a module to be used.

Overall, as a user, to a large degree, the delivery mechanism (rpm,
container/flatpak, and module) doesn’t affect me, except briefly at
install.

Overall, as a developer, today if my dependencies are modules, I have to
build a module. Tomorrow if my runtime dependencies are modules I have to
build a module, but otherwise I can build an “everything” repo rpm. I can
deliver via container or flatpak today no matter what.

As a system administrator, if my machines have internet access I may have
to learn a few new commands, but it all works. If my machines are getting
their software indirectly, my experience will vary based on whether my
indirection server can handle modules, flatpaks and containers.

Is this close to right?

Regards,

bex



>
> Tom
>
> On 12/02/2019 09:03, Igor Gnatenko wrote:
> > Not in the buildroot. Default modules are available by default only for
> > users and not in the buildroot.
> >
> > On Tue, Feb 12, 2019 at 10:01 AM Tom Hughes  > > wrote:
> >
> > On 12/02/2019 07:22, Mikolaj Izdebski wrote:
> >  > On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini
> > mailto:decatho...@gmail.com>> wrote:
> >  >> I'm curious: What happens to modules when a package's master
> branch
> >  >> gets retired?
> >  >
> >  > Nothing. Modules will continue to exist and will continue to be
> >  > delivered to users.
> >
> > But as I understand it the default module stream is available
> > in master anyway?
> >
> > So that does mean ant is a false positive because it's still
> > available as a module and the default stream will be available
> > in master?
> >
> > 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://getfedora.org/code-of-conduct.html
> > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
>
>
> --
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Nicolas Mailhot]

Le 2019-02-12 10:21, Emmanuel Seyman a écrit :

* Tom Hughes [12/02/2019 09:15] :


So basically the module squad have managed to ensure that everything
that relies on ant to build is going to have to modularise or else be
forced out of the distribution then...


Once more with feeling: if you want ant as a package, all that is 
needed

to make that happen is for you to step up and maintain it.

This has nothing to do with modularisation.


This has everything to do with modularisation.

Modularisation creates a situation where work results are no longer 
shared by default, so you can have someone that makes ant work in his 
own module, and the rest of the distro can not use it


That's the problem when the goal is to avoid software conflicts and the 
"solution" is to blindly partition things. You can not have partitioning 
without hitting the Fedora "share" value hard, unless you are very 
careful to put mecanisms in place so all the people that ask for 
partitioning still share things by default.


For every packager modules claim to woo because conflicting versions 
become possible, how many will be lost because the base Fedora system is 
drained from useful reusable packages and becomes useless?


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Tom Hughes]

On 12/02/2019 09:21, Emmanuel Seyman wrote:

* Tom Hughes [12/02/2019 09:15] :


So basically the module squad have managed to ensure that everything
that relies on ant to build is going to have to modularise or else be
forced out of the distribution then...


Once more with feeling: if you want ant as a package, all that is needed
to make that happen is for you to step up and maintain it.


Right, except I know nothing about Java so it's really not something
that I would be up to doing.

As I say I'm only affected because I have a library that has Java
bindings, and I didn't even package those myself - my original version
left them out and somebody else contributed them later.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Emmanuel Seyman]

* Tom Hughes [12/02/2019 09:15] :
>
> So basically the module squad have managed to ensure that everything
> that relies on ant to build is going to have to modularise or else be
> forced out of the distribution then...

Once more with feeling: if you want ant as a package, all that is needed
to make that happen is for you to step up and maintain it.

This has nothing to do with modularisation.

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Tom Hughes]

So basically the module squad have managed to ensure that everything
that relies on ant to build is going to have to modularise or else be
forced out of the distribution then...

Fortunately that only includes one thing of mine and that's just some
java bindings that I can drop but forcing libreoffice out of Fedora on
the hill of modularisation will certainly be an achievement of sorts.

Tom

On 12/02/2019 09:03, Igor Gnatenko wrote:
Not in the buildroot. Default modules are available by default only for 
users and not in the buildroot.


On Tue, Feb 12, 2019 at 10:01 AM Tom Hughes > wrote:


On 12/02/2019 07:22, Mikolaj Izdebski wrote:
 > On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini
mailto:decatho...@gmail.com>> wrote:
 >> I'm curious: What happens to modules when a package's master branch
 >> gets retired?
 >
 > Nothing. Modules will continue to exist and will continue to be
 > delivered to users.

But as I understand it the default module stream is available
in master anyway?

So that does mean ant is a false positive because it's still
available as a module and the default stream will be available
in master?

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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




--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Igor Gnatenko]

Not in the buildroot. Default modules are available by default only for
users and not in the buildroot.

On Tue, Feb 12, 2019 at 10:01 AM Tom Hughes  wrote:

> On 12/02/2019 07:22, Mikolaj Izdebski wrote:
> > On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini 
> wrote:
> >> I'm curious: What happens to modules when a package's master branch
> >> gets retired?
> >
> > Nothing. Modules will continue to exist and will continue to be
> > delivered to users.
>
> But as I understand it the default module stream is available
> in master anyway?
>
> So that does mean ant is a false positive because it's still
> available as a module and the default stream will be available
> in master?
>
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Tom Hughes]

On 12/02/2019 07:22, Mikolaj Izdebski wrote:

On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini  wrote:

I'm curious: What happens to modules when a package's master branch
gets retired?


Nothing. Modules will continue to exist and will continue to be
delivered to users.


But as I understand it the default module stream is available
in master anyway?

So that does mean ant is a false positive because it's still
available as a module and the default stream will be available
in master?

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Igor Gnatenko]

I was talking to Petr Šabata some time ago and he told me that there will
be some solution for getting modular packages in non-modular buildroot
within month or two.

On Tue, Feb 12, 2019 at 9:06 AM Aleksandar Kurtakov 
wrote:

>
>
> On Tue, Feb 12, 2019 at 9:51 AM Ralf Corsepius 
> wrote:
>
>> On 2/12/19 8:22 AM, Mikolaj Izdebski wrote:
>> > On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini 
>> wrote:
>> >> I'm curious: What happens to modules when a package's master branch
>> >> gets retired?
>> >
>> > Nothing. Modules will continue to exist and will continue to be
>> > delivered to users.
>>
>> Actually, I consider ant & Co's modularisation to be a non-helpful
>> mistake, which should be reverted ASAP.
>>
>
> There is nothing to revert actually. Packages are orphaned and all that's
> needed is someone to take them and maintain them.
>
> P.S. This imposes work on my team cause we would have to move Eclipse to a
> module too due to that but having maintained Ant & Maven stacks before I
> fully understand the need to make a clear separation between runtime and
> buildtime deps which can't be achieved with the pristine repo model.
>
>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Aleksandar Kurtakov]

On Tue, Feb 12, 2019 at 9:51 AM Ralf Corsepius  wrote:

> On 2/12/19 8:22 AM, Mikolaj Izdebski wrote:
> > On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini 
> wrote:
> >> I'm curious: What happens to modules when a package's master branch
> >> gets retired?
> >
> > Nothing. Modules will continue to exist and will continue to be
> > delivered to users.
>
> Actually, I consider ant & Co's modularisation to be a non-helpful
> mistake, which should be reverted ASAP.
>

There is nothing to revert actually. Packages are orphaned and all that's
needed is someone to take them and maintain them.

P.S. This imposes work on my team cause we would have to move Eclipse to a
module too due to that but having maintained Ant & Maven stacks before I
fully understand the need to make a clear separation between runtime and
buildtime deps which can't be achieved with the pristine repo model.


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


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Ralf Corsepius]

On 2/12/19 8:22 AM, Mikolaj Izdebski wrote:

On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini  wrote:

I'm curious: What happens to modules when a package's master branch
gets retired?


Nothing. Modules will continue to exist and will continue to be
delivered to users.


Actually, I consider ant & Co's modularisation to be a non-helpful 
mistake, which should be reverted ASAP.

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Mikolaj Izdebski]

On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini  wrote:
> I'm curious: What happens to modules when a package's master branch
> gets retired?

Nothing. Modules will continue to exist and will continue to be
delivered to users.

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Paolo Bonzini]

On 11/02/19 17:57, Miro Hrončok wrote:
> 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.
> 
> See this in your web browser or curl it at:
> 
> https://churchyard.fedorapeople.org/orphans-2019-02-11.txt
> 
> Please grep it for your username.

I can maintain nasm if no one else wants to take it.

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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Igor Gnatenko]

I don't think you can generate graph... Because how would you display
"Requires: (foo if bar)"? :)

On Mon, Feb 11, 2019 at 6:11 PM Adam Williamson 
wrote:

> On Mon, 2019-02-11 at 17:57 +0100, Miro Hrončok wrote:
> > The following packages require above mentioned packages:
> > (this is in fact so long that I've posted it to
> > https://churchyard.fedorapeople.org/orphans-2019-02-11.txt)
>
> It would be rather handy to get some sort of graph view, especially
> when the list is so complex...make it clearer what are the really
> important packages blocking lots of other stuff.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Tom Hughes]

On 11/02/2019 17:02, Adam Williamson wrote:


On Mon, 2019-02-11 at 17:57 +0100, Miro Hrončok wrote:

The following packages require above mentioned packages:
(this is in fact so long that I've posted it to
https://churchyard.fedorapeople.org/orphans-2019-02-11.txt)


It would be rather handy to get some sort of graph view, especially
when the list is so complex...make it clearer what are the really
important packages blocking lots of other stuff.


I think in this case ant and nasm are two of the main culprits.

Lots of things use ant obviously, and nasm kills libjpeg-turbo
which then kills a whole ton of things.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Adam Williamson]

On Mon, 2019-02-11 at 17:57 +0100, Miro Hrončok wrote:
> The following packages require above mentioned packages:
> (this is in fact so long that I've posted it to 
> https://churchyard.fedorapeople.org/orphans-2019-02-11.txt)

It would be rather handy to get some sort of graph view, especially
when the list is so complex...make it clearer what are the really
important packages blocking lots of other stuff.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org