On Sun, Feb 07, 2021 at 12:40:55AM +, Paul Wise wrote:
> I support having locate in the base install, but I don't think that
> the cost of daily walking the entire filesystem is low; especially
> with HDDs and older storage or computers that can be a lot of I/O. I
> guess it also alters the Lin
On Feb 06, "Steinar H. Gunderson" wrote:
> mlocate used to be Priority: standard; for some reason that I haven't been
> able to unearth (despite the efforts of several people), there is now an
Probably because long ago it replaced locate from findutils which used
to be standard too.
> release a
Executive summary: a re-transmit
On Wed, Feb 03, 2021 at 02:12:56PM +0530, Aditya Pratap Singh wrote:
> Hi,
> I have not yet seen any GSoC announcement this year.
> As far as I know the application period has started.
I like https://lists.debian.org/debian-mentors/2021/02/msg00027.html
> Will
On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
> I absolutely think that plocate makes sense as the "default" locate; it
> seems like an improvement on mlocate in every way.
>
> However, I don't think *any* locate should be in the base install, as
> long as that entails having any
Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves
* Package name: libmodule-install-substitute-perl
Version : 0.03
Upstream Author : Ruslan Zakirov
* URL : https://metacpan.org/release/Module-Install-Substitute
* License : Perl
Programming Lang: Per
On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
> locate is a purely user-facing tool,
> not really usable for portable scripting, since neither its presence nor
> its functioning can be assumed.
Really? Basic functionality is the same between locate.findutils, mlocate and
plocate.
Hello!
I just noticed how maintainers are NMU'ing packages in large quantities to
get them somehow in a usable state for the release. The packages get small
patches so that they are more or less working and can get into testing, despite
the packages being untouched for a long time in some cases me
John Paul Adrian Glaubitz writes:
> If the packages in question are essential, then these packages should get a
> proper
> maintainer with a maintenance release first before the freeze kicks in.
How does that happen?
Bjørn
Hello,
Just answering the subject.
John Paul Adrian Glaubitz, le dim. 07 févr. 2021 13:40:39 +0100, a ecrit:
> I just noticed how maintainers are NMU'ing packages in large quantities to
> get them somehow in a usable state for the release.
I don't think this is related to fixing the release date
John Paul Adrian Glaubitz writes:
> It shouldn't be enough for a package to have its worst bugs fixed like FTBFS
> or
> crashes when it gets shipped with a release. Packages that are being shipped
> with
> a release should also be properly maintained or not shipped at all.
For context, there a
On Sun, Feb 07, 2021 at 02:20:28PM +0100, Samuel Thibault wrote:
> > the packages being untouched for a long time in some cases meaning there is
> > no guarantee for quality.
>
> Sure, but if there is no serious issue left with the package, we can as
> well ship it.
Strictly speaking, there is a b
On 2/7/21 3:20 PM, David Bremner wrote:
> John Paul Adrian Glaubitz writes:
>
>> It shouldn't be enough for a package to have its worst bugs fixed like FTBFS
>> or
>> crashes when it gets shipped with a release. Packages that are being shipped
>> with
>> a release should also be properly mainta
On Sun, Feb 07, 2021 at 10:20:19AM -0400, David Bremner wrote:
> John Paul Adrian Glaubitz writes:
>
> > It shouldn't be enough for a package to have its worst bugs fixed like
> > FTBFS or
> > crashes when it gets shipped with a release. Packages that are being
> > shipped with
> > a release sh
On Sun, Feb 07, 2021 at 03:42:54PM +0100, John Paul Adrian Glaubitz wrote:
> >> It shouldn't be enough for a package to have its worst bugs fixed like
> >> FTBFS or
> >> crashes when it gets shipped with a release. Packages that are being
> >> shipped with
> >> a release should also be properly m
On Sun, Feb 07, 2021 at 01:40:39PM +0100, John Paul Adrian Glaubitz wrote:
> I just noticed how maintainers are NMU'ing packages in large quantities to
> get them somehow in a usable state for the release. The packages get small
> patches so that they are more or less working and can get into testi
On Sun, Feb 07, 2021 at 01:40:39PM +0100, John Paul Adrian Glaubitz wrote:
> I just noticed how maintainers are NMU'ing packages in large quantities to
> get them somehow in a usable state for the release.
what does 'large' mean here? 23? 230? 2300? >9000?
also, how many source packages & how ma
On Sun, Feb 07, 2021 at 10:20:19AM -0400, David Bremner wrote:
> John Paul Adrian Glaubitz writes:
>
> > It shouldn't be enough for a package to have its worst bugs fixed like
> > FTBFS or
> > crashes when it gets shipped with a release. Packages that are being
> > shipped with
> > a release sh
On Sun, Feb 7, 2021 at 9:58 AM Steinar H. Gunderson wrote:
> On my server, with ~12M files on rotating media, updatedb.plocate finishes in
> ~40 seconds, IIRC. (I'd re-check to be sure, but today is RAID Sunday... :-) )
> On my laptop with 875k files and a regular SSD, it's less than three. It doe
Andrey Rahmatullin, le dim. 07 févr. 2021 19:41:01 +0500, a ecrit:
> On Sun, Feb 07, 2021 at 02:20:28PM +0100, Samuel Thibault wrote:
> > > the packages being untouched for a long time in some cases meaning there
> > > is
> > > no guarantee for quality.
> >
> > Sure, but if there is no serious is
Andrey Rahmatullin writes:
> On Sun, Feb 07, 2021 at 02:20:28PM +0100, Samuel Thibault wrote:
>> > the packages being untouched for a long time in some cases meaning there is
>> > no guarantee for quality.
>>
>> Sure, but if there is no serious issue left with the package, we can as
>> well shi
On Sun, Feb 07, 2021 at 03:12:25PM +, Paul Wise wrote:
> On my desktop a no-change update takes 40s and the I/O usage is around
> 1800 K/s according to iotop-c, probably would be more painful on
> HDD-only systems.
That's interesting; how many files do you have on your machine, roughly?
(e.g.
On Sun, Feb 07, 2021 at 05:19:17PM +0100, Gard Spreemann wrote:
> >> > the packages being untouched for a long time in some cases meaning there
> >> > is
> >> > no guarantee for quality.
> >>
> >> Sure, but if there is no serious issue left with the package, we can as
> >> well ship it.
> > Stric
Andrey Rahmatullin writes:
> Strictly speaking, there is a big logical error here.
> If a package doesn't have RC bugs that doesn't mean it's fit for a
> stable release, doesn't have serious issues, or even is usable.
Yes, but if no one has reported any serious issues, I think we should
assume
John Paul Adrian Glaubitz writes:
> On 2/7/21 3:20 PM, David Bremner wrote:
>> John Paul Adrian Glaubitz writes:
>>> It shouldn't be enough for a package to have its worst bugs fixed like
>>> FTBFS or crashes when it gets shipped with a release. Packages that
>>> are being shipped with a release
On Sun, Feb 07, 2021 at 10:25:26AM -0800, Russ Allbery wrote:
> To me, the rewards of keeping the orphaned packages clearly outweigh the
> risks. If the package is actually broken, presumably sooner or later
> someone will notice and report that as a bug, and we can then take
> appropriate action.
Andrey Rahmatullin writes:
> On Sun, Feb 07, 2021 at 10:25:26AM -0800, Russ Allbery wrote:
>> To me, the rewards of keeping the orphaned packages clearly outweigh
>> the risks. If the package is actually broken, presumably sooner or
>> later someone will notice and report that as a bug, and we c
Le 07/02/2021 à 19:27, Russ Allbery a écrit :
> The more interesting question is what if there simply isn't resources to
> adopt them and maintain them properly. In that case, are we better off
> with them, or without them?
>
> I don't think this answer is obvious, but I would lean towards saying
Package: wnpp
Severity: wishlist
Owner: Klaumi Klingsporn
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: ruby-cssminify
Version : 1.0.2
Upstream Author : Matthias Siegel
* URL : https://github.com/matthiassiegel/cssminify
* License : expat
Progr
Package: wnpp
Severity: wishlist
Owner: Klaumi Klingsporn
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: webgen
Version : 1.7.1
Upstream Author : Thomas Leitner
* URL : http://webgen.gettalong.org
* License : GPL, LGPL, Expat
Programming Lang: R
Package: wnpp
Severity: wishlist
Owner: D Haley
* Package name: libatomprobe
Version : 20210207
Upstream Author : D Haley
* URL : http://apttools.sourceforge.io/
* License : GPLv3
Programming Lang: C++, Python
Description : Library for processing Atom
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: buildlog-consultant
Version : 0.0.1
Upstream Author : Jelmer Vernooij
* URL : https://github.com/jelmer/buildlog-consultant
* License : GPL
Pr
On Sun, Feb 7, 2021 at 4:20 PM Gard Spreemann wrote:
> Wouldn't it be quite the massive paradigm shift to give up on the notion
> of tracking problems (= bugs), and instead try to track positive
> attributes like fitness for release, though?
This is something that is already happening a bit in De
On Sun, Feb 7, 2021 at 4:45 PM Andrey Rahmatullin wrote:
> "make sure everything we ship in testing was checked manually before
> migrating"?).
The Debian CD team has an in-progress tool called ditto that is aimed
at manual testing, currently for CD images. Potentially it or
something like it co
Hi folks,
I would like to install the unsigned kernel packages instead of the signed
ones, but using linux-headers-amd64 and linux-image-amd64 I have to wait for
a signature being applied.
Obviously the signed kernel image and header packages for amd64 rely upon
information not being publicly av
34 matches
Mail list logo
