On 12/6/20 12:27 PM, Philipp Kern wrote:
> On 06.12.20 01:08, Paul Wise wrote:
>> On Sat, Dec 5, 2020 at 12:21 PM Matthias Klose wrote:
>>
>>> Maybe there is more. But there's no progress, or intent to fix every tool
>>> to be
>>> aware of binNMUs. Maybe it's better to rethink how sourceful
On 06.12.20 01:08, Paul Wise wrote:
> On Sat, Dec 5, 2020 at 12:21 PM Matthias Klose wrote:
>
>> Maybe there is more. But there's no progress, or intent to fix every tool to
>> be
>> aware of binNMUs. Maybe it's better to rethink how sourceful no-change
>> no-maintainer uploads could be done
On Sat, Dec 5, 2020 at 12:21 PM Matthias Klose wrote:
> Maybe there is more. But there's no progress, or intent to fix every tool to
> be
> aware of binNMUs. Maybe it's better to rethink how sourceful no-change
> no-maintainer uploads could be done without introducing the above issues?
`dch
On 12/1/20 11:56 AM, Simon McVittie wrote:
> On Tue, 01 Dec 2020 at 11:05:54 +0100, Jonas Smedegaard wrote:
>> Can someone remind me: Why is it that we cannot do arch-independent
>> auto-building?
>
> We can and do autobuild arch-independent packages (since 2015: on the
> timescale of
On Wed, 02 Dec 2020 at 11:15:44 +0100, Raphael Hertzog wrote:
> But this has the obvious downside that "${source:Version}" is unchanged
> and that you might have issues with dependencies against the arch: all
> package.
Yes, I already said that this is why OBS can't realistically do its builds
On Wed, 02 Dec 2020, Raphael Hertzog wrote:
> > potentially different content, breaking the important design principle
> > that things that are different should have different names.
[...]
> And as an aside, the archive has big holes when enforcing this "design
> principle":
>
Hi,
On Tue, 01 Dec 2020, Simon McVittie wrote:
> If I understand correctly, one of the ftp team's objections to discarding
> and rebuilding maintainer-uploaded binaries is that if I upload foo_1.2-3,
> and they discard my binary upload and rebuild it on the buildds, this
> would result in having
On Tue, Dec 01, 2020 at 12:28:38PM +0100, Julien Cristau wrote:
> On Tue, Dec 01, 2020 at 10:56:28AM +, Simon McVittie wrote:
> > Possible solutions:
> >
> > - Change at least 622 packages so they have something more like
> > Depends: foo-data (>= ${source:Version}), foo-data (<<
> >
On Tue, Dec 1, 2020 at 11:36 AM Julien Cristau wrote:
> Make no-change-other-than-version-bump source uploads easier?
`dch --rebuild` already exists, so this would just need support in
wanna-build/sbuild for generating such uploads and support in dak for
accepting sourceful uploads from
Le 01/12/2020 à 12:19, Jonas Smedegaard a écrit :
> Quoting Simon McVittie (2020-12-01 11:56:28)
>> On Tue, 01 Dec 2020 at 11:05:54 +0100, Jonas Smedegaard wrote:
>>> Can someone remind me: Why is it that we cannot do arch-independent
>>> auto-building?
>>
>> We can and do autobuild
On Tue, Dec 01, 2020 at 10:56:28AM +, Simon McVittie wrote:
> Possible solutions:
>
> - Change at least 622 packages so they have something more like
> Depends: foo-data (>= ${source:Version}), foo-data (<< ${source:Version}+c)
> (also hope that all of their maintainers can get those
On Tue, 01 Dec 2020 at 10:56:28 +, Simon McVittie wrote:
> We can and do autobuild arch-independent packages (since 2015: on the
> timescale of multi-release transitions, this is relatively recent).
>
> However, we cannot currently do arch-independent *binNMUs* [because...]
I've thought in
Quoting Simon McVittie (2020-12-01 11:56:28)
> On Tue, 01 Dec 2020 at 11:05:54 +0100, Jonas Smedegaard wrote:
> > Can someone remind me: Why is it that we cannot do arch-independent
> > auto-building?
>
> We can and do autobuild arch-independent packages (since 2015: on the
> timescale of
On Tue, 01 Dec 2020 at 11:05:54 +0100, Jonas Smedegaard wrote:
> Can someone remind me: Why is it that we cannot do arch-independent
> auto-building?
We can and do autobuild arch-independent packages (since 2015: on the
timescale of multi-release transitions, this is relatively recent).
Quoting Paolo Greppi (2020-12-01 10:53:11)
> Il 01/12/20 10:00, PICCA Frederic-Emmanuel ha scritto:
> > What about doing something similar to sphinx.
> > Create a package with the doxygen jquery and link to files of this package
> > for all documentations generated via doxygen.
> > provide a
Il 01/12/20 10:00, PICCA Frederic-Emmanuel ha scritto:
What about doing something similar to sphinx.
Create a package with the doxygen jquery and link to files of this package for
all documentations generated via doxygen.
provide a dh_doxygen to do this link like dh_sphinxdoc
Cheers
Fred
Quoting Andrius Merkys (2020-12-01 10:28:16)
> On 2020-12-01 11:00, PICCA Frederic-Emmanuel wrote:
> > What about doing something similar to sphinx.
> > Create a package with the doxygen jquery and link to files of this package
> > for all documentations generated via doxygen.
> > provide a
On 2020-12-01 11:00, PICCA Frederic-Emmanuel wrote:
> What about doing something similar to sphinx.
> Create a package with the doxygen jquery and link to files of this package
> for all documentations generated via doxygen.
> provide a dh_doxygen to do this link like dh_sphinxdoc
+1
In
Il 01/12/20 08:18, Niels Thykier ha scritto:
Russ Allbery:
The root problem, at least as I understand it, is that the two relevant
upstreams (and probably lots more) have followed those practices to vendor
and pin versions of jQuery, and are not regularly updating those pins, so
the current
Russ Allbery:
> The root problem, at least as I understand it, is that the two relevant
> upstreams (and probably lots more) have followed those practices to vendor
> and pin versions of jQuery, and are not regularly updating those pins, so
> the current version in Debian may or may not work.
As
Hi,
WordPress has a bunch of these dependencies which float in and out of
lining up between what Debian has and what upstream WordPress uses. As an
added bonus, they sometimes slightly adjust their copies.
I use lintian overrides and dh-linktree and this helps, but the result is
less than good
Wookey writes:
> Having read #903428 I see there is no enthusiasm for fixing this in the
> tooling. And also that I am not the only person coming across this and
> wondering what to do about it. I've had this experience before with both
> doxygen and javadoc and have spent some years assuming
I was just updating a package and got the using lintian grumbling that
javadoc has added 1.3MB of jquery to my package (almost doubling its
installed size).
There are 5 of these on my system (I'm surprised its not more
actually, surely some people must have tens or hundreds of these as
both
On Tue, Jan 8, 2019 at 4:42 AM Wookey wrote:
>
> On 2019-01-04 20:16 +0100, Samuel Thibault wrote:
> > Hello,
> >
> > Quite a few packages have jquery/ embedded in documentation generated by
> > javadoc. This yields to
> >
> > Could openjdk perhaps build a package that would ship jquery/ in a
On 2019-01-04 20:16 +0100, Samuel Thibault wrote:
> Hello,
>
> Quite a few packages have jquery/ embedded in documentation generated by
> javadoc. This yields to
>
> Could openjdk perhaps build a package that would ship jquery/ in a known
> place, and packages would just depend on it and the
Le 07/01/2019 à 23:02, Samuel Thibault a écrit :
> I'd rather cripple the documentation a bit than removing it :)
The issue is, we keep getting more and more javadoc related issues with
each OpenJDK upgrade. This jquery "issue" is a bit the straw that breaks
the camel's back, and we would rather
Emmanuel Bourg, le lun. 07 janv. 2019 22:25:35 +0100, a ecrit:
> Le 07/01/2019 à 21:13, Nicholas D Steeves a écrit :
> > Do you have any suggestions for working with the following?: (please
> > reply to -devel)
>
> We've discussed this topic in #903428 and the consensus is roughly that
> it's a
Hi Nicholas,
Le 07/01/2019 à 21:13, Nicholas D Steeves a écrit :
> Do you have any suggestions for working with the following?: (please
> reply to -devel)
We've discussed this topic in #903428 and the consensus is roughly that
it's a waste of time and we would rather drop the mostly unused
Dear Java Team,
Do you have any suggestions for working with the following?: (please
reply to -devel)
On Sun, Jan 06, 2019 at 10:34:50PM +0100, Rene Engelhard wrote:
> On Sat, Jan 05, 2019 at 09:20:34PM +0100, Samuel Thibault wrote:
> > Sean Whitton, le sam. 05 janv. 2019 19:48:35 +, a
On Sat, Jan 05, 2019 at 09:20:34PM +0100, Samuel Thibault wrote:
> Sean Whitton, le sam. 05 janv. 2019 19:48:35 +, a ecrit:
> > Forgive my ignorance of the specifics of this package, but why can't you
> > add symlinks to the files shipped by libjs-jquery? That is the standard
> > solution.
>
Sean Whitton, le sam. 05 janv. 2019 19:48:35 +, a ecrit:
> Forgive my ignorance of the specifics of this package, but why can't you
> add symlinks to the files shipped by libjs-jquery? That is the standard
> solution.
openjdk's javadoc not only includes libjs-query, but also jszip,
Hello Samuel,
On Fri 04 Jan 2019 at 08:16pm +0100, Samuel Thibault wrote:
> Quite a few packages have jquery/ embedded in documentation generated by
> javadoc. This yields to
>
> «
> libfoo-java shares 1.2 MB of similar files with package
> liblizzie-java-doc, please investigate whether it is
Hello,
Quite a few packages have jquery/ embedded in documentation generated by
javadoc. This yields to
«
libfoo-java shares 1.2 MB of similar files with package
liblizzie-java-doc, please investigate whether it is possible to reduce
the duplication.
»
e.g. most of the libbrlapi-java size comes
33 matches
Mail list logo
