Re: Proposal: plocate as standard for bookworm

[Steinar H. Gunderson]

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 Linux kernel block/filesystem caches?

updatedb.plocate, like updatedb.mlocate, doesn't actually watch the entire
filesystem. It keeps track of the mtime of each directory, and doesn't do the
readdir()/getdents() if it hasn't changed. So you get the cost of stat-ing
every directory, but that's actually fairly low.

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 does
alter the filesystem cache somewhat, but the amount of RAM used can be
bounded cgroups if desired; it runs from a systemd service.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Re: Proposal: plocate as standard for bookworm

[Marco d'Itri]

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 and non-release architectures. The only non-Essential dependencies
> are liburing1 (33 kB) and libzstd1 (670 kB).
libzstd1 is already a dependency of apt, so no big deal.

> I believe a good, fast locate is something that we should have in our base
> install; it is fine to keep it out of the cloud image (as today), but it is
> genuinely useful for both desktops and servers, and with a low cost.
I agree.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: GSoC 2021

[Geert Stappers]

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 Debian participate this year?

I don't know. But I think the question is

Has Debian for the year 2021 tasks that do exist
and have a mentor available for "Google Summer of Code"??


> Sorry if its just me who missed some announcement.

Thanks for sparking the discussion.  As in: No need to say sorry for
missing announcement that missed their audience.
 

> Kind regards
> Aditya


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: Proposal: plocate as standard for bookworm

[Holger Levsen]

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 kind of regularly scheduled task that
> indexes the filesystem [...]
 
agreed on everything. It's easy to install if needed/wanted.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

Make racists afraid again.


signature.asc
Description: PGP signature

Bug#982202: ITP: libmodule-install-substitute-perl -- Module::Install::Substitute - substitute values into files before install

[Dominic Hargreaves]

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: Perl
  Description : Module::Install::Substitute - substitute values into files 
before install

This is an extension for Module::Install system that allow you to substitute
values into files before install, for example paths to libs or binary
executables.

It will be maintained as part of the Debian Perl group.

Re: Proposal: plocate as standard for bookworm

[Steinar H. Gunderson]

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. Its presence can be resolved by... well, making it Priority:
standard. :-)

> Many users won't even know it exists
> (locate has far fewer users than find), and for all of those non-users,
> the effort spent building the database will go entirely to waste.

Sure, but that waste is fairly small. On a typical system, you're using a few
seconds every night.

> Furthermore, any mechanism they use to configure one of them
> (e.g. for privacy or performance reasons) will not control the other,
> and again they may well be unaware of the existence of the other one.

I'm not sure what privacy reasons you're referring to? I'm not aware that
neither mlocate/plocate nor e.g. tracker will leak data across users.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Fixed release dates are hurting quality

[John Paul Adrian Glaubitz]

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 meaning there is
no guarantee for quality.

I personally do not think that this is a good idea as this leads to the release
being shipped with lots of packages that have not been properly maintained and
the single NMU just paints over that issue.

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.

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. I don't
think we gain anything by shipping half-finished releases.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Fixed release dates are hurting quality

[Bjørn Mork]

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

Re: Fixed release dates are hurting quality

[Samuel Thibault]

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?

We want to manage to release at some point.

> 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.

Samuel

Re: Fixed release dates are hurting quality

[David Bremner]

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 are currently 929 packages maintained by
packa...@qa.debian.org. That doesn't count packages that have an
inactive maintainer, which is more challenging to quantify.

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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 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.
And if a package has an RC bug that doesn't mean it's not usable etc., it
just means it has some problem that fits the definition of an RC bug (or,
even, that doesn't, but nobody lowered the severity).
But the project decided to use these criteria in the absence of better
ones, just as the project decided to use obviously flawed popcon stats.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[John Paul Adrian Glaubitz]

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 maintained or not shipped at all.
> 
> For context, there are currently 929 packages maintained by
> packa...@qa.debian.org. That doesn't count packages that have an
> inactive maintainer, which is more challenging to quantify.

Yes, and I think that number 929 is already too high.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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 should also be properly maintained or not shipped at all.
> 
> For context, there are currently 929 packages maintained by
> packa...@qa.debian.org. That doesn't count packages that have an
> inactive maintainer, which is more challenging to quantify.
There were proposals for that, for example counting time and/or number of
uploads since the last maintainer upload.
On the other hand, there is vocal opposition in the project to calculating
whether a package is working/useful/should be removed based on its
maintenance status in Debian, its upload history, the history of its
upstream releases and similar things.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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 maintained or not shipped at all.
> > 
> > For context, there are currently 929 packages maintained by
> > packa...@qa.debian.org. That doesn't count packages that have an
> > inactive maintainer, which is more challenging to quantify.
> 
> Yes, and I think that number 929 is already too high.
Are you in favor of more aggressive package removal from testing or even
unstable? 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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 testing
Do you mean the process that happens for most of each testing freeze? As
my understanding is that this process is something normal and even
encouraged. Also, I'm not sure how is this related to "fixed release
dates" from the subject.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Holger Levsen]

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 many maintainers are "affected" in your
opinion?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

I'm looking forward to Corona being a beer again and Donald a duck.


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Adam Borowski]

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 should also be properly maintained or not shipped at all.
> 
> For context, there are currently 929 packages maintained by
> packa...@qa.debian.org. That doesn't count packages that have an
> inactive maintainer, which is more challenging to quantify.

Orphaned packages are nowhere as bad -- you can fix anything.

It's packages that are nominally maintained which see no updates but for RC
bugs.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ An imaginary friend squared is a real enemy.
⠈⠳⣄

Re: Proposal: plocate as standard for bookworm

[Paul Wise]

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 does
> alter the filesystem cache somewhat, but the amount of RAM used can be
> bounded cgroups if desired; it runs from a systemd service.

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. If you multiply that by all the Debian systems on
Earth it seems like a substantial amount of resource use.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Fixed release dates are hurting quality

[Samuel Thibault]

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 issue left with the package, we can as
> > well ship it.
> 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.

If a package has serious issues or is unusable, that makes it an RC bug,
and then the package will get removed, as it shall.

Of course, if nobody filed such an RC bug, the package gets shipped in a
broken state.  But it's perhaps better to just ship the package and let
people report in the case it is broken, rather than not ship it (despite
it is usable and has no serious issue ; no upload in a decade does *not*
necessarily mean that it has bitrotted), and then people not even notice
that the package isn't shipped any more.  I do have some packages on my
system which I do use, and which I just happened to notice that they are
not installable any more, because they got removed at some point.

Samuel

Re: Fixed release dates are hurting quality

[Gard Spreemann]

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 ship it.
> 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.

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?

 -- Gard
 


signature.asc
Description: PGP signature

Re: Proposal: plocate as standard for bookworm

[Steinar H. Gunderson]

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. plocate '' | wc -l)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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.
> > 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.
> 
> 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?
Sure, it would, and I'm not proposing it. Better QA would help us with
tracking bugs, on the other hand. It's debatable whether or not "better
QA" includes more of the manual testing (like "get more users"? "get more
users that are able to report bugs"? "do that by improving the reporting
experience"? "make sure people that are able to report bugs actually use
everything we ship in testing"? "make sure everything we ship in testing
was checked manually before migrating"?).

I'm also not sure what is the author of this thread proposing regarding
this.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Russ Allbery]

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 that it's usable.

Think of it in terms of a risk trade-off: If we toss orphaned packages or
packages with inactive maintainers, the upside is that we are less likely
to ship broken packages that have a low enough usage that no one has
reported the brokenness, and the downside is that we may remove packages
that someone is still using and cares about and that work fine for them.

If we keep those packages, the upside is that if they are working they
continue to work.  The downside is that they may be silently broken... but
in that case if no one is using them to know that they're broken, all
they're wasting is disk space and possibly an unpleasant surprise in the
rare case that someone stumbles across them.

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.

The exception, I suppose, is that we probably shouldn't keep shipping
packages that are orphaned and that no one is using, just on clutter
grounds, but that seems like a smaller problem that would be
better-handled by other mechanisms than a blanket rule for unmaintained
packages.

-- 
Russ Allbery (r...@debian.org)  

Re: Fixed release dates are hurting quality

[Russ Allbery]

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 should also be properly maintained or
>>> not shipped at all.

>> For context, there are currently 929 packages maintained by
>> packa...@qa.debian.org. That doesn't count packages that have an
>> inactive maintainer, which is more challenging to quantify.

> Yes, and I think that number 929 is already too high.

I think everyone agrees that it would be better if those packages were
adopted.  Forcing them to be adopted to remain in the distribution may
spark some adoption (although it may also backfire and spark adoption by
people seeking solely to keep them in the release but without any real
intent of working on them).

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
we're better off with them.

-- 
Russ Allbery (r...@debian.org)  

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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.
> 
> The exception, I suppose, is that we probably shouldn't keep shipping
> packages that are orphaned and that no one is using, just on clutter
> grounds, but that seems like a smaller problem that would be
> better-handled by other mechanisms than a blanket rule for unmaintained
> packages.
There are also other, though I think rare, considerations, like security
problems.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Russ Allbery]

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 can then
>> take appropriate action.

>> The exception, I suppose, is that we probably shouldn't keep shipping
>> packages that are orphaned and that no one is using, just on clutter
>> grounds, but that seems like a smaller problem that would be
>> better-handled by other mechanisms than a blanket rule for unmaintained
>> packages.

> There are also other, though I think rare, considerations, like security
> problems.

Yes, security is a worry, and security problems in orphaned packages fall
primarily on the security team instead of on the maintainer.  If there are
packages of concern to the security team from a supportability standpoint,
I certainly would support them in asking for them to be adopted or
removed.

Thankfully, most packages in the archive don't tend to have meaningful
security problems, in the sense that they don't listen to the network and
don't have unusual privileges, so are only likely to cause problems if
they're somehow run on untrusted input.  (Which was probably your point
about being rare.)

-- 
Russ Allbery (r...@debian.org)  

Re: Fixed release dates are hurting quality

[Alexis Murzeau]

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
> we're better off with them.
> 

The recent re-upload of xserver-xorg-video-*
drivers is a good example of (maybe) unmaintained but useful packages.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955603

Several xserver-xorg-video-* (like xserver-xorg-video-r128) were
removed by this bug because:
> They are either unmaintained upstream or provide no value to the
> distribution.

But were still being useful for users as shown by these comments on
#955603:
> Please keep these drivers. They work as just fine, and many people
> still use them. They have not been dropped by upstream X.org, and there
> is no reason to drop them from Debian. Without these drivers, it will
> make running Debian desktop on this hardware impossible. One of the
> things that makes Debian great is the backward compatibility. It's very
> sad to see destructive actions like this being taken. Please don't just
> throw away all the work that people have put into these drivers over
> the years, and please don't orphan their users!

Another comment:
> those modules are STILL IN RECENT SERVERS like r128 (rage) and
> openchrome via boards
> 
> proliant hp and DELL ones!


These drivers were reintroduced last friday.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



signature.asc
Description: OpenPGP digital signature

Bug#982260: ITP: ruby-cssminify -- CSS minification with YUI compressor, but as native Ruby port

[Klaumi Klingsporn]

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
  Programming Lang: Ruby
  Description : CSS minification with YUI compressor, but as native Ruby 
port

The CSSminify gem provides CSS compression using YUI compressor. Instead
 of wrapping around the Java or Javascript version of YUI compressor it uses a
 native Ruby port of the CSS engine.

The package is a dependency of webgen, a static website generator which I also
would like to get back into Debian.

I would like to package and maintain this program under the umbrella of the 
ruby team.

Bug#982261: ITP: webgen -- CSS minification with YUI compressor, but as native Ruby port

[Klaumi Klingsporn]

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: Ruby
  Description : fast, powerful, and extensible static website generator

Webgen is used to generate static websites from templates and content
files (which can be written in a markup language). It can generate
dynamic content like menus on the fly, knows partial website regeneration
(only modified items get re-generated) and comes with many powerful
extensions.

Webgen was in Debian nearly a decade ago but was removed because it was 
orphaned.
But I continued to maintain some websites with this program, therefore built my
personal packages of every new version of the program and would like to see it 
back in
Debian.

I would like to package and maintain this program under the umbrella of the 
ruby team.

Bug#982265: ITP: libatomprobe -- Library for Atom Probe Tomography computations

[D Haley]

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 Probe Tomography (APT) data

 This provides a C++ library for the scientific analysis
 of real valued point data (x,y,z,value). This is primarily targeted
 towards Atom probe tomography applications, but may prove useful to
 other applications as well.
 .
 The package includes both its own C++ and SWIG based python interfaces

This package provide tools for processing mass spectra data from Atom
Probe systems, such as developed by Ametek. Functions in the library
include spectra processing algorithms, 3D point data computation, and
file IO routines for specific APT types.

It is anticipated that this will become a future dependency for the
existing 3Depict package. This is intended to be maintained as part of
the Debian Science team.

There are no other packages that provide the coverage of data processing
routines in APT, as this is specialised research equipment.

A sponsor is needed, to quality-check and ultimately for upload.

Bug#982271: ITP: buildlog-consultant -- builg log parser and analyser

[Jelmer Vernooij]

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
  Programming Lang: Python
  Description : build log parser and analyser

buildlog-consultant can parse build logs and highlight and extract
the key error lines. This can be used to display a snippet from a build
log with the actual problem.

This functionality is factored out from debian-janitor, and a dependency
for ognibuild.

Re: Fixed release dates are hurting quality

[Paul Wise]

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 Debian:

The Debian CD team are testing images before each release and point release.

https://wiki.debian.org/Teams/DebianCD/ReleaseTesting

At one point there was systematic testing of the secure boot stuff:

https://wiki.debian.org/SecureBoot/Testing

The LTS team have manualish testing of packages they fix security issues in:

https://wiki.debian.org/LTS/TestSuites

The u-boot maintainer/users record the status of various uploads:

https://wiki.debian.org/U-boot/Status

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Fixed release dates are hurting quality

[Paul Wise]

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 could be adapted towards registering manual test
procedures and allowing folks to walk through those procedures and
record results. The release team could potentially use that
information as input into the testing migration process.

https://ditto.debian.net/
https://wiki.debian.org/Teams/DebianCd/ditto

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

how to ignore signed kernel packages and use the unsigned instead?

[Harald Dunkel]

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 available, making it impossible (or at least
pretty unlikely) for me to rebuild the dpendencies for linux-headers-amd64
and linux-image-amd64 on my own.

So I wonder if linux-headers-amd64 and linux-image-amd64 shouldn't depend
upon the unsigned kernel-headers and kernel-image packages, as for other
platforms?


Regards
Harri