On 2/2/23 10:16, Vít Ondruch wrote:
Hi,
I have spend some quality time bringing rubygem-railties test suite
up2date and this resulted in dropping the dependency on
rubygem-jquery-rails. Nothing else in Fedora depends on that package and
therefore I orphaned it and I suggest to let it go
Hi,
I have spend some quality time bringing rubygem-railties test suite
up2date and this resulted in dropping the dependency on
rubygem-jquery-rails. Nothing else in Fedora depends on that package and
therefore I orphaned it and I suggest to let it go.
Since I don't maintain rubygem-j
I plan to orphan js-jquery-noty unless someone wants to maintain it.
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
ít Ondruch wrote:
> > > According to [1], these are the packages which need to be
> > > preserved to
> > > keep js-jquery around:
> > >
> > >
> > > nodejs-grunt-legacy-util
> > >
> > > nodejs-load-grunt-tasks
> > >
&g
eng/issue/9077
>
> > Tom
> >
> > On 03/12/2019 07:45, Vít Ondruch wrote:
> > > According to [1], these are the packages which need to be
> > > preserved
> > > to
> > > keep js-jquery around:
> > >
> > >
> > > no
be preserved to
> > keep js-jquery around:
> >
> >
> > nodejs-grunt-legacy-util
> >
> > nodejs-load-grunt-tasks
> >
> > nodejs-raw-body
Yes, I started it awhile ago and made some progress. I think it's
still broken though; I lost track of where I&#
t Ondruch wrote:
> > According to [1], these are the packages which need to be preserved
> > to
> > keep js-jquery around:
> >
> >
> > nodejs-grunt-legacy-util
> >
> > nodejs-load-grunt-tasks
> >
> > nodejs-raw-body
> >
> >
I have taken nodejs-raw-body and am pushing an updated version to rawhide
now.
-Jared
On Tue, Dec 3, 2019 at 2:53 AM Vít Ondruch wrote:
> According to [1], these are the packages which need to be preserved to
> keep js-jquery around:
>
>
> nodejs-grunt-legacy-util
>
> no
Ben Rosser was working on sorting out grunt. In fact I believe he
took the first of those at least.
Tom
On 03/12/2019 07:45, Vít Ondruch wrote:
According to [1], these are the packages which need to be preserved to
keep js-jquery around:
nodejs-grunt-legacy-util
nodejs-load-grunt-tasks
According to [1], these are the packages which need to be preserved to
keep js-jquery around:
nodejs-grunt-legacy-util
nodejs-load-grunt-tasks
nodejs-raw-body
Vít
[1] https://churchyard.fedorapeople.org/orphans-2019-12-02.txt
Dne 03. 12. 19 v 2:24 Sérgio Basto napsal(a):
> I will t
I will take nodejs-dateformat .
Do you have a list of what more packages we have to keep?
On Mon, 2019-12-02 at 15:52 +0100, Raphael Groner wrote:
> Thanks a lot.
>
> Am 02.12.19 um 15:20 schrieb Tom Hughes:
> …
> > As I explained the other day js-jquery was dependent on a
&g
Thanks a lot.
Am 02.12.19 um 15:20 schrieb Tom Hughes:
…
As I explained the other day js-jquery was dependent on a
nodejs module (a normal one, not modularised) which was
failing to build and which I have now fixed.
…
___
devel mailing list -- devel
onsible for.
As I explained the other day js-jquery was dependent on a
nodejs module (a normal one, not modularised) which was
failing to build and which I have now fixed.
The only part of the nodejs stack that is modularised is
the actual nodejs engine - the large set of modules from npm
are just normal
> I don't think modularity is to blame here.
Nah. The dependent nodejs stack broke away due to move into modularity
worlds.
> 3) since the bundling policy is relaxed, everybody just bundles with
zero motivation to maintain package for somebody else.
Ack. The unbundling of js-jsquery has been a
Dne 28. 11. 19 v 19:43 Raphael Groner napsal(a):
> Hi,
>
> in case of my packages, jpype and pyvirtualize, I'd say to skip
> generation of documentation while js-jquery is b0rken.
>
> What's the issue about js-jquery? I tend to blame modularity due to
> nodejs-*.
Hi,
in case of my packages, jpype and pyvirtualize, I'd say to skip
generation of documentation while js-jquery is b0rken.
What's the issue about js-jquery? I tend to blame modularity due to
nodejs-*.
Just my 5ct.
Regards, Raphael
Am 28.11.19 um 14:05 schrieb Miro Hrončok:
Dear m
I have orphaned js-jquery-file-upload.
___
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
Would anybody like to maintain js-jquery-file-upload? If not, I will
orphan it.
https://src.fedoraproject.org/rpms/js-jquery-file-upload
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel
as I have no use for it and nothing depends on it.
I have also updated it prior to orphaning.
Regards,
--
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
$SUBJ, as I have no use for it.
--
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://g
On Sat, 27 Apr 2019 11:12:48 -0700
Kevin Fenzi wrote:
> On 4/26/19 8:53 AM, stan wrote:
> > On Fri, 26 Apr 2019 11:07:54 - (UTC)
> > Petr Pisar wrote:
> >
> > I am a fedora user with no dog in this fight.
> >
> >> Controversial property of modules are private build-time
> >> dependencie
On Sat, 27 Apr 2019 11:19:06 -0400
Neal Gompa wrote:
> The restrictions by Fedora Koji prevent that, but yes, MBS and
> Modularity do allow for something like this. It can't happen in Fedora
> because our Koji is not set up to consume external repositories
> (except for EPEL, which consumes RHEL
On 4/26/19 8:53 AM, stan wrote:
> On Fri, 26 Apr 2019 11:07:54 - (UTC)
> Petr Pisar wrote:
>
> I am a fedora user with no dog in this fight.
>
>> Controversial property of modules are private build-time dependencies.
>> Modularity allows packagers to hide them and to not to support them
>>
On Sat, Apr 27, 2019 at 11:20 AM Neal Gompa wrote:
>
> On Fri, Apr 26, 2019 at 11:53 AM stan wrote:
> >
> > On Fri, 26 Apr 2019 11:07:54 - (UTC)
> > Petr Pisar wrote:
> >
> > I am a fedora user with no dog in this fight.
> >
> > > Controversial property of modules are private build-time depe
On Fri, Apr 26, 2019 at 11:53 AM stan wrote:
>
> On Fri, 26 Apr 2019 11:07:54 - (UTC)
> Petr Pisar wrote:
>
> I am a fedora user with no dog in this fight.
>
> > Controversial property of modules are private build-time dependencies.
> > Modularity allows packagers to hide them and to not to s
On Fri, 26 Apr 2019 11:07:54 - (UTC)
Petr Pisar wrote:
I am a fedora user with no dog in this fight.
> Controversial property of modules are private build-time dependencies.
> Modularity allows packagers to hide them and to not to support them
> (to the extend that they work in my module).
On Thu, Apr 25, 2019 at 8:25 PM Miro Hrončok wrote:
> There was the packager UX initiative draft [2] proposed in December 2018,
> however it seems nobody really is eager to go and start doing this.
> It seems that this is a bit too much for volunteers and Red Hat paid Fedora
> contributors are alr
On Fri, Apr 26, 2019 at 3:23 PM Nicolas Mailhot
wrote:
>
> Le jeudi 25 avril 2019 à 20:00 -0400, Christopher a écrit :
> > Fighting with the "Modularity team", whoever they are
> > (a SIG? a mailing list?, a team at RedHat? ... I don't really know
> > who they are)
>
> Just to be clear: this is no
Le jeudi 25 avril 2019 à 20:00 -0400, Christopher a écrit :
> Fighting with the "Modularity team", whoever they are
> (a SIG? a mailing list?, a team at RedHat? ... I don't really know
> who they are)
Just to be clear: this is not about fighting the Modularity team (or
any other team, for that ma
On 2019-04-26, Miro Hrončok wrote:
> On 26. 04. 19 10:55, Vít Ondruch wrote:
>> How does modularity make it easier though?
>>>
>>> It seems to me that it does the exact opposite - instead of having
>>> one version of each package to maintain I now have multiple versions
>>> to worry about! I mean
Dne 26. 04. 19 v 11:15 Miro Hrončok napsal(a):
> On 26. 04. 19 10:55, Vít Ondruch wrote:>> How does modularity make it
> easier though?
>>>
>>> It seems to me that it does the exact opposite - instead of having
>>> one version of each package to maintain I now have multiple versions
>>> to worry a
On 26. 04. 19 10:55, Vít Ondruch wrote:>> How does modularity make it easier
though?
It seems to me that it does the exact opposite - instead of having
one version of each package to maintain I now have multiple versions
to worry about! I mean obviously I could convert to a module and
only main
Dne 25. 04. 19 v 20:37 Tom Hughes napsal(a):
> On 25/04/2019 19:29, Stephen John Smoogen wrote:
>>
>>
>> On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot
>> mailto:nicolas.mail...@laposte.net>>
>> wrote:
>>
>> Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit :
>> >
>>
On 26. 04. 19 2:00, Christopher wrote:
On Thu, Apr 25, 2019 at 2:39 PM Tom Hughes wrote:
On 25/04/2019 19:29, Stephen John Smoogen wrote:
On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot
mailto:nicolas.mail...@laposte.net>> wrote:
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallaghe
On Thu, 25 Apr 2019 at 20:01, Christopher
wrote:
> On Thu, Apr 25, 2019 at 2:39 PM Tom Hughes wrote:
> >
> > On 25/04/2019 19:29, Stephen John Smoogen wrote:
> > >
> > >
> > > On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot
> > > mailto:nicolas.mail...@laposte.net>>
> wrote:
> > >
> > > Le mer
On Thu, Apr 25, 2019 at 2:39 PM Tom Hughes wrote:
>
> On 25/04/2019 19:29, Stephen John Smoogen wrote:
> >
> >
> > On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot
> > mailto:nicolas.mail...@laposte.net>> wrote:
> >
> > Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit :
> >
On 25/04/2019 19:29, Stephen John Smoogen wrote:
On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot
mailto:nicolas.mail...@laposte.net>> wrote:
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit :
>
> FWIW, things should *not* be getting harder. Some folks just jumpe
On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot
wrote:
> Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit :
> >
> > FWIW, things should *not* be getting harder. Some folks just jumped
> > the gun and made changes they weren't supposed to (yet) and now the
> > Modularity team has a
On 25. 04. 19 12:13, Vít Ondruch wrote:
> The reasons are the same as why I keep alive the other versions. I'm not
> really going to maintain it unless I am totally bored. Also, there are
> other dependencies which are going to be orphaned soon, so I might
> change my mind ...
I have claimed the d
Dne 24. 04. 19 v 21:31 Christopher napsal(a):
> I'm orphaning js-jquery, since I do not have time to maintain it.
I requested unorpahing js-jquery:
https://pagure.io/releng/issue/8308
The reasons are the same as why I keep alive the other versions. I'm not
really going to maintai
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit :
>
> FWIW, things should *not* be getting harder. Some folks just jumped
> the gun and made changes they weren't supposed to (yet) and now the
> Modularity team has a lot of fires to put out and very few resources
> with which to
On Wed, Apr 24, 2019 at 4:15 PM Stephen Gallagher wrote:
>
> On Wed, Apr 24, 2019 at 3:33 PM Christopher
> wrote:
> >
> > I'm orphaning js-jquery, since I do not have time to maintain it.
> >
> > It's getting harder to contribute to Fedora with all th
On Wed, Apr 24, 2019 at 3:33 PM Christopher wrote:
>
> I'm orphaning js-jquery, since I do not have time to maintain it.
>
> It's getting harder to contribute to Fedora with all the mass
> orphaning of dependencies, and I don't have time to figure it all out.
>
I'm orphaning js-jquery, since I do not have time to maintain it.
It's getting harder to contribute to Fedora with all the mass
orphaning of dependencies, and I don't have time to figure it all out.
This is one that needs frequent attention, as jQuery is subject to
lots of vulne
The review request for the separate js-jquery2 package is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1441399
On Tue, Apr 11, 2017 at 3:32 PM Christopher
wrote:
> I want to update js-jquery to jQuery 3 (it is currently 2). So, I'm going
> to follow the rename procedure to renam
I want to update js-jquery to jQuery 3 (it is currently 2). So, I'm going
to follow the rename procedure to rename js-jquery to js-jquery2.
Afterwards, instead of retiring js-jquery, I'll update it to version 3.
This ensure a proper upgrade path for packages which need version 2,
sp
ave
> to ask
> if that is even appropriate in a released version anyway...
>
>
> Even if we ignore, it doesn't resolve the question about what to do
> with the compat packages for jquery1 (and maybe a future compat
> package for jquery2).
BTW jquery-rails now bundles jQ
ased version anyway...
>
>
> That's a good question. I'm not sure. It really depends on what API
> changes upstream is making, and who depends on the js-jquery1 compat
> package.
rubygem-jquery-rails depends on js-jquery1 [1] and it is already broken
in Rawhide [2]. Upda
On Tue, Nov 29, 2016 at 8:13 PM Tom Hughes wrote:
> On 30/11/16 01:02, Christopher wrote:
>
> > Can anybody help me build js-jquery1 for F24? I keep getting some NodeJS
> > and/or Grunt error with uglify, but only for the F24 branch. I want to
> > update the package, and I can get all the other b
On 30/11/16 01:02, Christopher wrote:
Can anybody help me build js-jquery1 for F24? I keep getting some NodeJS
and/or Grunt error with uglify, but only for the F24 branch. I want to
update the package, and I can get all the other branches to build just
fine (including EPEL7, F25, and rawhide), b
Can anybody help me build js-jquery1 for F24? I keep getting some NodeJS
and/or Grunt error with uglify, but only for the F24 branch. I want to
update the package, and I can get all the other branches to build just fine
(including EPEL7, F25, and rawhide), but F24 is broken even before I apply
any
On 22 July 2016 at 10:29, Vít Ondruch wrote:
>
>
> Dne 21.7.2016 v 15:12 Stephen Gallagher napsal(a):
> > On 07/21/2016 09:02 AM, Vít Ondruch wrote:
> >> Hi,
> >>
> >> Is there chance that somebody more familiar with JS than me would update
> >>
Dne 21.7.2016 v 15:12 Stephen Gallagher napsal(a):
> On 07/21/2016 09:02 AM, Vít Ondruch wrote:
>> Hi,
>>
>> Is there chance that somebody more familiar with JS than me would update
>> jQuery in Fedora? It would be nice to have jQuery 3.x as well. Or should
>> I
On 07/21/2016 09:02 AM, Vít Ondruch wrote:
> Hi,
>
> Is there chance that somebody more familiar with JS than me would update
> jQuery in Fedora? It would be nice to have jQuery 3.x as well. Or should
> I do the update myself?
>
> I am asking since I need to update rubyge
Hi,
Is there chance that somebody more familiar with JS than me would update
jQuery in Fedora? It would be nice to have jQuery 3.x as well. Or should
I do the update myself?
I am asking since I need to update rubygem-jquery-rails, which requires
the recent versions of jQuery (and it will require
On Mon, Jun 29, 2015 at 7:37 AM, Vít Ondruch wrote:
> If web client had a chance to say "hey, i have a /jquery.js in the
> cache from application A with checksum 'bla', I can reuse it for
> application B, since it request /jquery.js with the same checksum".
> Actually just checking checksums coul
On Mon, Jun 29, 2015 at 6:58 AM, Stephen Gallagher wrote:
> That doesn't really help, since the main advantage to this Change
> Proposal is having a single package to update when fixes are needed,
> but nearly all web applications take pieces of jQuery out and minify
> them (taki
SCo for a previous Fedora release. It has only been submitted
now for final announcement, since it was not complete by the Change
Freeze.
Turning back now would require blocking packages from the distribution
and reverting patches to packages that already depend on js-jquery*.
This cannot be done
On Mon, Jun 29, 2015 at 04:20:11PM +0200, Reindl Harald wrote:
> a web client is not allowed to say "hey, i have a /jquery.js in the
> cache from application A and re-use it for application B" because
> that would be *easy* attack vector
If only this was possible ...
https://rwmj.wordpress.com/20
l web applications take pieces of jQuery out and minify
them (taking only the parts they need in order to reduce download and
processing time to speed up execution).
Honestly, how much web applications do we have packaged?
And also, I am not convinced the the practice "take out some part of
Dne 29.6.2015 v 16:20 Reindl Harald napsal(a):
>
> Am 29.06.2015 um 16:13 schrieb Vít Ondruch:
>>> That doesn't really help, since the main advantage to this Change
>>> Proposal is having a single package to update when fixes are needed,
>>> but nearly all
Am 29.06.2015 um 16:13 schrieb Vít Ondruch:
That doesn't really help, since the main advantage to this Change
Proposal is having a single package to update when fixes are needed,
but nearly all web applications take pieces of jQuery out and minify
them (taking only the parts they need in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dne 29.6.2015 v 15:58 Stephen Gallagher napsal(a):
> On Mon, 2015-06-29 at 15:54 +0200, Vít Ondruch wrote:
>> Dne 29.6.2015 v 13:18 Stef Walter napsal(a):
>>> 1. How will compatibility issues be handled? In the case of
>>>
On Mon, 2015-06-29 at 15:54 +0200, Vít Ondruch wrote:
> Dne 29.6.2015 v 13:18 Stef Walter napsal(a):
> > 1. How will compatibility issues be handled? In the case of
> > Cockpit,
> > jQuery forms part of our future plugin API guarantees.
> >
> > The web
Dne 29.6.2015 v 13:18 Stef Walter napsal(a):
> 1. How will compatibility issues be handled? In the case of Cockpit,
> jQuery forms part of our future plugin API guarantees.
>
> The web application loses control of its dependencies, which normally
> form a intimate part of th
On 24.06.2015 02:01, Jan Kurik wrote:
> = Proposed System Wide Change: jQuery =
> https://fedoraproject.org/wiki/Changes/jQuery
>
> Change owner(s): T.C. Hollingsworth com>
>
> jQuery is a fast, small, and feature-rich JavaScript library. It
> makes things like HTM
= Proposed System Wide Change: jQuery =
https://fedoraproject.org/wiki/Changes/jQuery
Change owner(s): T.C. Hollingsworth
jQuery is a fast, small, and feature-rich JavaScript library. It makes things
like HTML document traversal and manipulation, event handling, animation, and
Ajax much
= Proposed System Wide Change: jQuery =
https://fedoraproject.org/wiki/Changes/jQuery
Change owner(s): T.C. Hollingsworth
jQuery is a fast, small, and feature-rich JavaScript library. It makes things
like HTML document traversal and manipulation, event handling, animation, and
Ajax much
68 matches
Mail list logo
