Bug#1020400: ITP: cif2hkl -- Convert crystallographic descriptions into HKL F^2 reflection lists

[Roland Mas]

Package: wnpp
Severity: wishlist
Owner: Roland Mas 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: cif2hkl
  Version : 1.4.1
  Upstream Author : Emmanuel Farhi 
* URL : 
https://gitlab.com/soleil-data-treatment/soleil-software-projects/cif2hkl
* License : GPL2+
  Programming Lang: Fortran
  Description : Convert crystallographic descriptions into HKL F^2 
reflection lists

A program that computes structure factors |F^2| for neutrons, x-rays,
and electrons from CIF/CFL/SHX/PCR crystallographic descriptions.
This is useful to compute the diffraction pattern from materials.  It
can be used for generating .lau/.laz files for e.g. McStas.

I will maintain this package under the debian-science team on Salsa.

Bug#1020401: ITP: orderedset -- Ordered Set implementation in Cython

[Roland Mas]

Package: wnpp
Severity: wishlist
Owner: Roland Mas 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: orderedset
  Version : 2.0.3
  Upstream Author : Simon Percivall 
* URL : https://github.com/simonpercivall/orderedset
* License : BSD
  Programming Lang: C/Python
  Description : Ordered Set implementation in Cython

An Ordered Set implementation in Cython. Based on Raymond Hettinger's
OrderedSet recipe.

Features:
- Works like a regular set, but remembers insertion order;
- Is approximately 5 times faster than the pure Python implementation
  overall (and 5 times slower than set);
- Compatible with Python 2.7 through 3.8;
- Supports the full set interface;
- Supports some list methods, like index and __getitem__.
- Supports set methods against iterables.

This package will be maintained within the Python team on Salsa.

Re: R³ by default: not for bookworm

[Adam Borowski]

On Sun, Sep 18, 2022 at 03:58:57AM +0200, Guillem Jover wrote:
> On Sun, 2022-09-18 at 03:39:43 +0200, Adam Borowski wrote:
> > A few packages had a value of R³ other than "no" / "binary-targets",
> > these are deprecated now; bugs filed.
> 
> Deprecated by who or what?

I had the impression https://bugs.debian.org/975637 has passed.

> > The process of adding/changing a field in "control" differs between the
> > three source formats we have.
> 
> Hmm, I'm not sure I understand this statement.

In 3.0 formats, you can unpack a tarball (whose name differs by format),
update debian/control, repack -- no need to apply the quiltage or touch
any other fragile bits.  In 1.0 you need to go through all the motions --
I don't even see (in dpkg-source's man page) how to skip running "clean"
which in turn requires B-Deps and can fail.

> > Of these, the most involved format is 1.0 -- you need to repack the
> > whole source. And quite a bunch of packages fail that step, not even
> > letting me to modify anything.  I guess FTBS bugs need to be enforced...
> 
> Nor this one. Could you give more details?

Fails To Build Source.  Ie, ｢dpkg-source -x｣ then ｢dpkg-source -b｣ fails.
I tend to use sbuild for repacking, the whole incantation is:

alias sbuild-source='sbuild -s --source-only-changes --no-arch-all 
--no-arch-any --no-run-autopkgtest'

> > Almost any format 1.0 package with R³ unset does so not because of an
> > actual need for fakeroot, but because of an ancient build system and a
> > decade or two of neglect.
> 
> Lack of debhelper/dh usage certainly makes adding the field more
> challenging, yes.

Another common error are hardcoded whoami checks.

> > Format "3.0 (native)":
> > The complete list of packages that FTBFS if you set them to R³:no is:
> > Format "3.0 (quilt)":
> > In a pile of build logs that looks incomplete:
> > 408 Status: attempted
> >   12387 Status: successful
> 
> Thanks for these checks! But in addition to checking whether these failed,
> did you check that they ended up with the same user:group and perms (such
> as SUID), as before setting the field?

I only checked whether they build; that'd be the next step if the change to
the default looked plausible.

> > Thus: let's revisit R³ being required after Bookworm.
> 
> My current thinking though, has been to change the default via something
> like:
> 
>   

Adding a yet another field everyone has to bump would be costly in human
time.  I wonder, perhaps it'd be better to hijack dh compat -- at the cost
of a bogus b-dependency for a small fraction of packages?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ * ***
⠈⠳⣄

Bug#1020411: RFP: sphinxcontrib-ditaa -- sphinx extension for embedding block diagram using ditaa

[Bastian Germann]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: sphinxcontrib-ditaa
  Version : 1.0.1
  Upstream Author : Yongping Guo 
* URL : https://pypi.org/project/sphinxcontrib-ditaa/
* License : BSD-2-clause
  Programming Lang: Python
  Description : sphinx extension for embedding block diagram using ditaa

ditaa is a command-line utility that can convert diagrams drawn using ascii art 
into bitmap graphics.
This sphinx extension allows using these conversions in a sphinx doc.

Bug#1020433: ITP: bettercap-caplets -- Bettercap scripts (caplets) and proxy modules

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-devel@lists.debian.org, vil...@debian.org

* Package name: bettercap-caplets
  Version : 0+git20210429-1~exp1
  Upstream Author : the dev team 
* URL : https://github.com/bettercap/caplets
* License : GPL-3
  Programming Lang: JavaScript
  Description : Bettercap scripts (caplets) and proxy modules

  This package contains Bettercap scripts (caplets) and proxy modules. The
  bettercap's interactive sessions can be scripted with .cap files, or caplets.

Bug#1020438: ITP: libtwiggy-tls-perl -- Twiggy server with TLS support

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtwiggy-tls-perl
  Version : 0.0020
  Upstream Author : Serhii Zasenko 
* URL : https://metacpan.org/release/Twiggy-TLS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Twiggy server with TLS support

Twiggy is a lightweight and fast HTTP iserver that can run PSGI 
applications.

Twiggy::TLS adds TLS support via Twiggy::Server::TLS - a subclass of
Twiggy::Server.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Re: 'The' timestamp of a snapshot of deb.debian.org

[Roland Clobus]

Hello all,

Thank you all for your replies so far.

On 19/09/2022 16:41, Mattia Rizzolo wrote:

On Sun, Sep 18, 2022 at 10:58:37AM +0200, Roland Clobus wrote:

All of these timestamps (for sid) are close to each other, but not
identical. I would guess that the earliest timestamp is the 'real'
timestamp, but it is accessible (on snapshot.d.o) only with a later
timestamp.


Consider that the archive "freezes" when it starts working on an update.
Once it finishes its job it generates the Release files, and puts the
current timestamp *inside* the file.  But then that file gets copied
around, signed, etc and that will change the timestamp.


So if the archive is frozen when it starts to work on an update, that 
moment sounds to me as 'the' timestamp of the archive.
Change Request: Could that timestamp be preserved and used for the 
timestamp inside the (In)Release file, instead of using 'now' (which is 
slightly later) when generating the (In)Release file?



Also, for example, I just spotted a line on IRC saying that this time
around copying the archive from the live one to archive.debian.org also
reset the mtimes...


In the live-build scripts, I reset the mtime of such generated files to 
have them match their content.



So I really wouldn't trust mtimes in any way, only what's inside the
Release file.


Ack.


What's in the trace file is IIRC the time when the archive kicks the
mirrors off, which also happens after the generation of the indexes, and
really has no business in this discussion as it's only a tool mirrors
use to coordinate and see if they are too much out of sync.


The trace file is currently used in the live-build scripts, but I'll 
change that to use (In)Release instead.



As you noticed snapshots indexes by time of the archive run, which is…
honestly I don't particularly consider it a good idea myself but that's
how the design decision went I guess.


The timestamps of snapshot.d.o are the only timestamps that I currently 
know that allow me to re-generate older images.
Change Request: Could the use the timestamp from (In)Release instead of 
'now' as well?


As to the origin of my question:
The snapshot-mirror has been offline for a while, and I've used 
deb.debian.org to generate my test images (for the reproducible 
live-build-based live-ISO images). I've compared the timestamps of the 
InRelease file at deb.d.o with the timestamp in the URL available on 
snapshot.d.o and I've noticed a difference.
That means that all images that I've generated using deb.d.o cannot be 
verified at any later moment than within the same dak-round (which last 
for 6 hours).
Now that the snapshot-mirror is online again, I'll use that timestamp 
again, and thus I'll be able to generate the same image from any 
required timestamp. So effectively 'the' timestamp is found in the URL 
of snapshot.d.o, but I would like to have that one identical to the 
timestamp of InRelease.


With kind regards,
Roland Clobus


PS: Regarding these change requests: I could write some patches, but I'm 
still busy getting the reproducible live-images onto the automated 
testing platform and after confirmation of their proper functioning on 
the official Debian download pages (so it will take some time, before I 
can work on that. If anyone would be faster than I would be: thanks in 
advance)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020450: ITP: golang-github-allan-simon-go-singleinstance -- Run only one instance of a software

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-allan-simon-go-singleinstance
  Version : 1.0.0-1
  Upstream Author : Allan Simon
* URL : https://github.com/allan-simon/go-singleinstance
* License : Expat
  Programming Lang: Go
  Description : Have only one instance of a software running

 Cross plateform library to have only one instance of a software (based
 on python's tendo
 (https://github.com/pycontribs/tendo/blob/master/tendo/singleton.py)).

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Re: 'The' timestamp of a snapshot of deb.debian.org

[Johannes Schauer Marin Rodrigues]

Quoting Roland Clobus (2022-09-21 22:03:33)
> As to the origin of my question: The snapshot-mirror has been offline for a
> while, and I've used deb.debian.org to generate my test images (for the
> reproducible live-build-based live-ISO images). I've compared the timestamps
> of the InRelease file at deb.d.o with the timestamp in the URL available on
> snapshot.d.o and I've noticed a difference.  That means that all images that
> I've generated using deb.d.o cannot be verified at any later moment than
> within the same dak-round (which last for 6 hours).

Why not? Just check which package versions your image contains and find the
correct snapshot.debian.org timestamp(s) containing all these packages via
metasnap.debian.net.

signature.asc
Description: signature

UsrMerge vs cruft

[Alexandre Detiste]

Hi,

It looks like UsrMerge finally broke the "cruft" engine for good.

As a mix of bash, Perl and ad-hoc C helpers,
it has be unmaintainable and mostly unmaintained for so many years.

request bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941998
RM request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020293


I wasn't notified about the RM request and stumbled on it by luck,
but I won't oppose it, and will consider moving the
rule database that is now in cruft-common into cruft-ng;
although in a smarter concatenated format, to avoid
wasting inodes with tiny 1 line files.

Does cruft-ng needs to start providing a transitional "cruft" binary package
/ command for pre-existing users, or is this such a niche Q&A utility
(in the likes of adequate, piuparts, diffoscope, lintian) that it can go 
without ?

cruft-ng still has ways to evolve, for example by processing the globing 
patterns
for R/W files provided in AppArmor templates by more and more packages.


Any comments are welcome.

Greetings,

Alexandre Detiste


pgpvytoB7j1BL.pgp
Description: OpenPGP digital signature

Re: Temporary freezes of udeb-producing packages for d-i releases

[Cyril Brulebois]

Hi dd@,

Cyril Brulebois  (2022-09-12):
> Looking at the previous release cycles, such freezes usually last for a
> few days only, from a given debian-installer upload until installation
> images have been built successfully, and haven't found to be crippled
> with obvious bugs.

There were some hiccups along the road, but here we are…

> The freeze for the Debian Installer Bookworm Alpha 1 release should
> happen this week, and will be lifted as soon as the release is
> published.

… freeze lifted seconds ago.

Hopefully we won't need 10 days every time!

Thanks for your patience and understanding.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature