Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Jonas Smedegaard]

Quoting noisyc...@tutanota.com (2024-09-21 23:06:42)
> > If you never offered to maintain resvg then how did this conversation
> > emerge? Did I try to bend your words, when all you initially said was
> > "whoops" and informing me that it was a bleep on the radar soon gone?
> > If that's the case then I apologize for the confusion I have caused:
> > Please simply continue correcting your mistake, no need to elaborate on
> >all the possible ways *others* than yourself can handle the package
> > onwards.
> 
> What I was trying to say initially was: I made a mistake and I can back off, 
> but given the work I already did, including the binaries and completing the 
> packaging is very easy (I already kinda did it at this point), so if anyone 
> is interested in actually maintaining the binaries (I am not) they can just 
> stick their names on it and have resvg+usvg back in Debian with little 
> effort. Unless Jonas wants to complete the packaging, in which case he should 
> have precedence anyway since he expressed interest in doing this for quite a 
> while.
> 
> > I kindly ask you to *maintain* what you choose to maintain in Debian.
> 
> > I do not like it if you maintain without fully maintaining, regardless
> > of the amount.
> 
> > [I] am confused why you uploaded at all
> 
> As I'm sure you know, even if you may disagree, it is within the Rust Team's 
> packaging policy to only build the library and not the binaries. This is not 
> considered to be "not fully maintaining". I agree that it's preferable to 
> build everything available in the source however (especially if the binaries 
> were already in Debian and not totally new!), this is why I insisted from the 
> start that it would be nice if someone could use my work and upload the 
> binaries too. When you said you were not specifically interested in the 
> package I took it literally and thought that if no one was interested in 
> building the whole package, then only uploading the libraries (which on the 
> contrary are very much needed) would be enough. I apologize for the 
> misunderstanding.

WTF?

No, I was unaware of this additional deviation from Debian.  Thanks for
bringing it to my attention.  Knowing that, it makes better sense that
you can be talking about the option to taking over a package while not
even caring to mention that if doing so, you will be ditching the
executable part of it.


> You saying you are interested in having the whole resvg in Debian is
enough for me, I'll take care of whatever is left in NEW.

Thanks.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1082544: please upgrade to v0.22

[Jonas Smedegaard]

Source: rust-tree-sitter
Version: 0.20.10-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to, or separately provide, branch v0.22.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbvMO0MHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhHM4P/R2NJP9uEUR5OOHGugGZGSMHTOr6a+j93NviY1UO
V2BzIIyTtMj2Bc14cInhMOuY4p8XKBZU1XqNBiCqjiaIzRhqYYOPzvhwNTqS4/Ki
wRsAweIKsJTW0wQ8fA7EMdJx0J4oaI8k4691D4eTDBdrCOYNo0khhVVJXu2RGKHc
Zg8zjcXeyuaYNZbZWDhd1SSXXA35F18jV1s9yztCrbGMIaMUIUUmUMex5N3vTMH4
v0q6dUilIwYLMIaLkgnfThfozlJrrCRlw06YVCLdBpxahY6yqX2VfD6g35TrCf/c
giwnImxLkyNFzvkNDSQ1H1a/9UW/2APNozVON0QYigZqLAfel/G76kmKPJwlUETR
11zWlUyyAG3vOHcOP71T6N4bcDDwx9YYCnsxNV9WB6mIzVRhbZMNnn9pw53TVvNf
2xZnS2c/J4wwLtLMP3bC02MBZzf3pX14v03a4iE2iUGjAkbk0L2/ym4URfMucfJB
MnXTYkRIeBW1BPvGXNVCS2qXnrJj3akDfmzLBNAuxGrKXatHX9IkiXV53PFe6Gay
sFWknXDqGDuMyqUq5kwOVMF5koL9EtN4OqcFJzb5LCfnphzCFZYOzKc32Spvzsgk
Tyr+mDwjoZEemb+vSukN19o+r2/1x6M6nhY9oaT60oNHO8CO+Uima3VA4IEcNujq
NaZc
=Sc6x
-END PGP SIGNATURE-

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Jonas Smedegaard]

Quoting noisyc...@tutanota.com (2024-09-21 21:59:50)
> Jonas, you must have missed one piece of my first email, which I report below:
> 
> > Jonas, I apologize for the duplicated work. Since you've been working on 
> > this
> > for a long time I am more than willing to step down from {u,re}svg once the
> > sources are rejected. I am no user of resvg and I am not interested in
> > maintaining it other than to provide the rust library.
> 
> ("once the sources are rejected" to me reads as "when the sources are 
> rejected", not "if", because I'd still expect rejection for the reasons I 
> explained). So I agree with you, and I said it from the first time: I am more 
> than willing to back off. No reason to do otherwise.
> 
> Then I wrote:
> 
> > if someone from the Rust Team (in cc) wanted to maintain resvg we could
> > also remove src:resvg from unstable and go forward with my (sponsored)
> > uploads. I am ok with both solutions, but I would like Jonas to have the 
> > final
> > word on this given his longstanding interest in resvg.
> 
> Meaning if no one from the Team is interested, provided that you still are, 
> I'd rather not go forward with the uploads. If rejection is not automatic and 
> I'll have to get in touch with the FTPMasters, then I will. The reason why I 
> pinged you in private about this thread earlier today is precisely because 
> the FTPMasters are going forward with my NEW uploads and I need an answer as 
> soon as possible so I know what to do.
> 
> But then you answered
> 
> > I have no special interest in maintaining these packages
> 
> from which I gathered... you're not interested? So if you're not interested, 
> I'm not interested, no one from the Team showed up to signal interest, the 
> package was removed from testing... then why should I want to re-upload the 
> binaries? No issue with the long-term maintenance of the libraries, which I 
> do need as a dependency, but the binaries?
> 
> This being said, if you are going to maintain resvg+usvg in whatever form you 
> like, then thank you as it will mean less work for me. Please confirm you're 
> going to do so, this way I know how to deal with the packages in NEW.

I have an interest in resvg staying in Debian.

I have no special interest in me being the person ensuring that resvg
stays in Debian.

If you take over maintenance of resvg, and you do that by only caring
for the library, and adding back the executable and its man page only if
someone else does the work for you, then I would rather add resvg as
package number 663 in the horribly long list of packages I have taken
responsibility for.

What is the short version of the above 3 sentences? That I prefer to
maintain resvg or that I prefer to not maintain resvg?

I kindly ask you to *maintain* what you choose to maintain in Debian.

I highly appreciate that you maintain packages in Debian, regardless of
the amount.

I do not like it if you maintain without fully maintaining, regardless
of the amount.  Then I prefer to pile more onto my own list.  But no, I
really do not prefer to maintain more packages.

If you uploaded by accident, and don't want to maintain what you
uploaded, then I (am confused why you uploaded at all, and) want you to
simply say "whoops" and correct your mistake.  Not offer to maintain the
package if you are not really willing to do that.

If you never offered to maintain resvg then how did this conversation
emerge? Did I try to bend your words, when all you initially said was
"whoops" and informing me that it was a bleep on the radar soon gone?
If that's the case then I apologize for the confusion I have caused:
Please simply continue correcting your mistake, no need to elaborate on
all the possible ways *others* than yourself can handle the package
onwards.

Thanks,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Jonas Smedegaard]

Quoting noisyc...@tutanota.com (2024-09-21 20:36:55)
> > Introduction of a binary package in another source package is not a reason
> > for rejection, as I understand it: That sounds like the only way to, well, 
> > doing
> > exactly that: Move a binary package to being maintained in another source
> > package.
> 
> Sure, but I would expect at least removal of the older source package from 
> unstable first, or explicit consent from the previous maintainer to the 
> overtake.
> 
> > So please go ahead and take over maintenance of these packages (if also
> > ok with the previous maintainer, Andrej Shadura, obviously), just make
> > sure that you take over all of it, not only the library parts.
> 
> I pushed the changes to debcargo-conf's current packaging of usvg/resvg 
> needed to build the binaries to my personal repo: 
> https://salsa.debian.org/NoisyCoil/debcargo-conf/-/commits/usvg-resvg. As far 
> as the binaries are concerned, packaging-wise, only the manpages are missing 
> (and proper d/changelog entries). C-library packages are not included as they 
> are not built by neither package (nor they could be within debcargo-conf 
> IIUC). Still, as I've already expressed in my last emails, I am not 
> interested in maintaining the binaries. If Andrej, or tarzeau (both in cc), 
> or really anyone else, is interested in doing so, they can just signal their 
> interest and I'll add them to the Uploaders, add the manpages and re-upload 
> the packages (again, through to my sponsor). Otherwise I see no value in 
> re-uploading packages no-one is actually interested in maintaining, all the 
> more if they were already removed from testing.

N, no no - that's not how we are playing this!

Either you take over and you *maintain* the project, or you back off.

Doing a one-off release of the easy part - the library only, and then
instead of stepping up and doing the rest you argue that falling out of
testing is an indication that it is irrelevant? Come on - grow up!

I take back my endorsement. Please clean up the mess you did with your
accidental one-off relase, and let people that care for long-term and
proper maintenance handle it.

Or do the right thing and *care* for the package!  The whole thing.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1082521: nmu: mptcpd_0.12-4

[Jonas Smedegaard]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: mpt...@packages.debian.org
Control: affects -1 + src:mptcpd
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

nmu mptcpd_0.12-4 . ANY . unstable . -m "relink against libell"

ell restructured its API slightly, which requires a rebuild of its
dependencies. There is no SONAME bump, since upstream treats the API as
unstable, and Debian has only two reverse dependencies (iwd and mptcpd)
which are handled manually.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbu2SsMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhTf0P/3qclMNyhDWG5ZghtY7/P3b2IdRq50D6ZrjlOmiu
5wTi+99SWXLJtdkXZu26piECxgTo3F8gtd9AhdyuwOQKDevpAv9r96HDWJArqdkz
MLoe26OB5HNmv5E1M/mPECAZS2K1jqp+jLM4eudZXNMsxeeUq/Qw9KT/vXIIFvca
H4TG08IXAHOlwRd66k9JiFteQmcFEdNf4Q44ucTfAxzQHSEJluopfBmtNEyly1Qq
rxpQF8oWszUL0HEecUAWJZbaN9oiu/YEqf0LM8cRthRicrCTMdchA/sUVDCN7iYo
OrJfASiJm3O7MA2K1E7e8xfJakeq0I0P1ohQFRZ1ON6w7iTI3Os25IOsLR2X/8Ns
HNRg9eTctRXqobNyU7Czy1bSKSWocqJhIQWI3IWNEZrHRASsIfbJ7NFLfkHKUZWL
qo/7z5+mk/f+bFj3hk5/bScY6t6sws557LsojNbjhCFnf+WCkgVWij9GA/baCxi0
+Ifjqv+GnM/XfAiy+FlWb3NuAYZ1MOjqwICWYgssolx8fboZ4dJX48ZN4Q4on5h4
LA4EaUZumQNWlPcrNX+M0XVp0PHxh78utOwwX4YbkftKiZgtdYbMxGLqNujOsu7e
he9AK89TvuUB0C33mwyD772NXFOPXYXW/t+QJ+qBGWVizdr5uJ3MUR9NmxobMLo+
/pQi
=yDJq
-END PGP SIGNATURE-

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Jonas Smedegaard]

Hi NoisyCoil (and Andrej),

> Right now src:rust-usvg and src:rust-resvg are in NEW and will
> probably be rejected since they build librust-{u,re}svg-dev, which
> albeit having been removed from testing are still in unstable.

Introduction of a binary package in another source package is not a
reason for rejection, as I understand it: That sounds like the only way
to, well, doing exactly that: Move a binary package to being maintained
in another source package.

While I don't expect the package to be rejected, please do anyway
immediately upload an update to your packages which provides also the
executables, to avoid bothering ftpmasters twice with a NEW processing.

Yes, I have invested quite some time into packaging these, but my time
has been mainly in building from true source (not from pre-generated
not-preferred-form-for-editing assets distributed via crates.io), and
composing a sensible migration path from previous maintenance to that
(in my opinion) ideal packaging style. I have no special interest in
maintaining these packages, however, and if your packaging style is
different then there is no need for the work I have spent time on.

So please go ahead and take over maintenance of these packages (if also
ok with the previous maintainer, Andrej Shadura, obviously), just make
sure that you take over all of it, not only the library parts.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1081747: meli: encrypting mail fails

[Jonas Smedegaard]

Quoting Matthias Geiger (2024-09-20 20:31:01)
> On Sat, 14 Sep 2024 14:52, Matthias Geiger  wrote:
> >Package: meli
> >Version: 0.8.7+20240912+dfsg-1
> >Severity: important
> >X-Debbugs-Cc: werdah...@debian.org
> >
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA256
> >
> >Hi,
> >decrypting mail now works. However, I can't send signed mail:
> >
> >"gpgme: Call to sign() with zero keys"
> >
> >The config file looks like this:
> >
> >[pgp]
> >auto_sign = true 
> >auto_verify_signatures = true
> >sign_key = "ECBEDBB607B9B2BE"
> >
> >best,
> >
> >werdahias
> >
> Hi Jonas,
> 
> upstream fixed this with this PR [0].
> 
> Please consider cherrypicking this into Debian.

Ah, I saw that commit and wondered if it was related to this report of
yours.  Let me give it a try.  Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1082133: please upgrade to branch v4

[Jonas Smedegaard]

Source: rust-termion
Version: 1.5.6-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to, or separately provide, newer upstream branch v4.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbrCPUMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEh2DUP/R7mSG5xEonI5R2cquz1Ops659RYaNyUrlYnuyTR
EdqBy8VdYhca2xOrQm0BOycStfO4C7JHcPxP41+SdmTeg/N/qv8YUtyrAegJULm6
4DbFE+ub2qZPC1DS4KMB95Ez7D8n+WGkzbQMN9zonAfC1ixH7dqWq3FhyBgEYyZb
onGgBvjNrR+DrbxiJrI81uqAIO+iPn807Ue8cnYEVCd4uq8R1arjD57ziyfaBUBU
yi0iE+dYQEBXJWN/tvpewNDmK/z7XmS4O73CGuV3woeynQsTcxVLZSoeFs5pFOgQ
SK7PCMi0IetI4mRiWzthhsWLB2ZtJ/ZIGyKzA6aEqPVh9tuPCvwzaQdGylXO8Xv2
TcXeB+/pcHHyaNqdeJVJn9EyOjdVg9+iwNjbJsCmv1TgaHpzd0kEE49Ov8710acF
yHd781R0losz68w7EGCe1Rc7TKkO337bg0pABRfRinNuvdwi+c3LUHiUykUXR5HF
f1VRBM/+kx1XdcW6R6FgratkRXb7iuAS1G/JkDOPmK7eo6DgE3VqbPNBsqBlHRrX
q0YmwZ9JTAxoidowQFYLF5JIVTEEKiES47APGN3R59U/fsC9I/W9MvM9fFedvrtL
RrabXpXo/bvpvM5Jx6VAJ/Fv4XklX3XYnTsjytlWA/elk4vSD5KpQcSfv1p3kYCV
69tS
=Ifz5
-END PGP SIGNATURE-

Bug#1081784: ITP: rust-human-panic -- panic messages for humans

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-human-panic
  Version : 2.0.1
  Upstream Contact: Yoshua Wuyts 
* URL : https://github.com/rust-cli/human-panic
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : panic messages for humans

 human-panic provides panic messages for humans.
 It handles panics by calling std::panic::set_hook
 to make errors nice for humans.

This package is needed for sdml (bug#1064145).
It will be maintained in the collaborative debian section of salsa, at
<https://salsa.debian.org/debian/rust-human-panic>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbl1IsMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEh3ZEP/0rH8DTzCr2nrg/Zcr46Z5CV5XXq24X9bygqPcFh
yBazr3DNtxX9AoiE2GjDVWSVJ2MRyZ12UXKUuUqDijsI+9Mz4ZsC/qjPz9NznADJ
caYEIw4tpDcm97S9BIZslrUN/kIOIZUtVV5n5oUow+oahKt3wyXcYxpd+MrSoxaR
OvbI0Q/TT+EF9Z3H5pmBDPKQB+4DNg/MzQLX90l6Us7blAEa1qerdM6AkCJQ4SLr
GDA+sFDBQ838kCwi+PHUj+0UwsyC6saanWNT+2scTfSs2y3dAiNWr6JX/DQm6t7n
3eJn1hMYyrJ3TUQuI1GRJ6/u1eAsuwcYB7RUztq6a/ELDmxwtLKekeNBmnIvQQgE
CGDkIgHPmMbsLq6t7bCzsGO6OLVUUAnGbVRZ8qA/ncLRKkMxPNMTYL0W1CAqpFLG
QKHlGcjsh/IsVGHwvV6eod0uC0tNllXLxmotL0Prh6bmjSr5izj6qkkjtAINJIHI
/Lj1EoTVChRZbL5xO16XnKS5y6RV8oUOm4pGaa/kppPVOXOh5ppX6WirxuSQ4rcs
bX9ugsNG1tOztoYNZynbYk3c7H6+c59tBftNMtO8qc7QUqj/Rlm+OYFQkwSQfh0o
BIpNXpZgC8FvVt+8/xEaqOCalKwzaIqRJij0yWf7Qu75B1kDdwxqUj1waxX+NOrB
ZSJV
=vmrm
-END PGP SIGNATURE-

Bug#1081778: ITP: rust-search-path -- very simple search path file finder

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-search-path
  Version : 0.1.4
  Upstream Contact: Simon Johnston 
* URL : https://github.com/johnstonskj/rust-search_path
* License : Expat
  Programming Lang: Rust
  Description : very simple search path file finder

 The SearchPath type allows for the finding of files
 using a series of search directories.
 This is akin to the mechanism a shell uses
 to find executables using the PATH environment variable.
 It can be constructed with a search path from an environment variable,
 from a string, or from a list of either string or Path/PathBuf values.
 Typically the find methods return the first matching file or directory,
 but the find_all method specifically collects and returns a list
 of all matching paths.

This package is needed for sdml (bug#1064145).
It will be maintained in the collaborative debian section of salsa, at
<https://salsa.debian.org/debian/rust-search-path>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmblz/QMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhpN8P/Ru/THrY44pLbeM1rPOPKe+jzK7Sq1HLgK/VHPM8
dTKRjEDob8u1iTyNM7RoMR3ugS/BIrOfs41ZUlhSadNypMklXStOXQnZAjlVSLQ0
5NypokqncF4Aqk/C/d+UCR6vN0TZ1Th89jzLtG4tBpZ5a/zdXMBpH1Ffi+HbzCfx
wkKyBherm/kz+P4K56NYg22f+cYZex+JcnoaOa4Nsq94ehOkB50tZ+WYndNVyuU4
+RnzYlaV9NOOvJXfXIwClQn3ZDmjpYQnh6u2Ov3yE+umyfSIZqRPDmGQKixNcBHT
cic8SMAjpUPg0VSKorj10D10M7KY8ne7sN+wSsfBlmLUGgtrQA4/d5hne927wzzQ
0+maosbG4I+L+n/+skE8n2j0DCZop1FdD+HEloR+R6fY6RcY98Z2099+ELcsC7W9
eukQJYwhahdmbbmwHDW0th5J0PZaRm3bMQmJU+H5dSB/8rnvpCxu9fQ9fH74EPFp
ckcRDt8NAwf6Q2QEMO8ABLooTkW4UilYDaZ7SD6OAsBnIQPWj40VFjD0lNWFMnPL
HD0lovFwHE4P2Bmfqs5WzlJ2LlwDUnSBS8iygAstVi2b7EBGwXy/jVqWYp8CsczB
D1iRuWEVjVKAPd4Bjj0O7cz3l/+hXiIp6KPqUNEMb9arBPTzkrbyLBg4kb0YASs0
c0yb
=XgXO
-END PGP SIGNATURE-

Bug#1081775: ITP: rust-text-trees -- simple textual output for tree-like structures

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-text-trees
  Version : 0.1.2
  Upstream Contact: Simon Johnston 
* URL : https://github.com/johnstonskj/rust-text_trees
* License : Expat
  Programming Lang: Rust
  Description : simple textual output for tree-like structures

 text-trees will output a tree structure in text.
 Similar to the ascii_tree crate,
 however it is more flexible in its formatting options.

This package is needed for sdml (bug#1064145).
It will be maintained in the collaborative debian section of salsa, at
<https://salsa.debian.org/debian/rust-text-trees>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbly/IMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhRiUQAKAWIsg113ukHTH4q7HaxjsO0UthslF7EF3Dgkqw
OZFNjvnGRVDF3THORALuAoXkEezXY8DlnUHjbJwVP7p+hiJXqh8tRT70g35+JEHD
CeG0XmMjIYm/Dpne7wCloBtKo25kuUeQ2QG6+YMhQdaWJ2paMQgPJGWnbpzFmBgW
5kX2fYZheAw8CmUhIcDE0IWvSblXS2zvkuWzX3ZmRL0uIuYXd2dWP3CUkRzcnjiT
TbRZlwv563zaESLUwJjbZZicoI9MXhkLOgTfBwXjC/pPkyeeNQJTZvDD/sZ9+Vrw
fmW9sApXkIjHjLnaK2z0DBJLPdGHsWitUr5LGqEtqddwKnzfValTfeNXpfE3cFyB
MMtODozHivOB0WiCLz6rZhY2nF5u6MjCUoGQ1RNhpZk1kYQ1C2jKS8LiYLiX82NQ
vGyLtB7fdFUmqEW+Rm5TLnAlnlYm8IX63474j6Sq57TEJ1px06HDwMuksqzBMntt
vHEzTUQv/CjO03e2x8J6QcynnHH0gY/2rT6T5rpLQ3ZC9zCMGE6gQMadT3bF19tQ
eRTZKPQSdV6w59Gjm7QjP7FqK9039AuQV3ve7pORxMIcEC29tvyKjSjEie8bqmV4
/JfMaYV2gl0mHx1NnXqmudvT32jsIfLLszDGbhU0GlLFWzlBL8IkIYHgSrJkVHUD
99w/
=gBvl
-END PGP SIGNATURE-

Bug#1081755: ITP: rust-serde-qs -- querystrings for Serde

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-serde-qs
  Version : 0.13.0
  Upstream Contact: Sam Scott 
* URL : https://github.com/samscott89/serde_qs
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : querystrings for Serde

 serde_qs is is a Rust library
 for serialising to and deserialising from querystrings.
 It is designed to extend serde_urlencoded
 when using nested parameters,
 similar to those used by qs for Node,
 and commonly used by Ruby on Rails via Rack.

This package is needed for rust-indieweb (bug#1081745).
It will be maintained in the collaborative debian section of salsa, at
<https://salsa.debian.org/debian/rust-serde-qs>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmblny0MHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhpoEP/i8wMr6UrBbTglrr8DAaC40+qYf6rWVeGYopVCVw
fBCLxm1F8SpXY+heZlfKD2gyRxMo+gUNjLWWaQ9+mKanoGRtl56MXZlgcOJHcn8E
XQYG8nAO/nCPNZmIG4NV9qX3r8OClLc4Hk/dI81+ZYkxV/Ep5sfQ1fqjOTk0fEJp
QOC5/y/CiAiGmLhAZ3ISgyIf3xxENsCom+uF5jajOShiigFeXCWtc1d4Xk9oKqUS
tKsJddmT0l+waSyCoGhc//dI4dpB713vfq+5+KAcAKfPKfciOlLRy0POb/zTwy+T
tYxG/1pIztCZ1Dg9EMefypsXw7B7ZH2vxy4fhzUCwje0BSMSH6lfsufq3CKKJpC6
mBN7R7dxYGlqsUhrnjHtmEOiGUyzQIwKVSBQSuNrv4zRvyeeE1/L1pQyPcv8g0al
aDt+P0MDQgHnprc7PbGPYGslxcKpspUA0mmOrIJIozk7Ohpx8JuyuB+hBgYFLBgO
Loa0aY1ZgaFg9c7XXQrVxy4spB4wRMKvGZb6B0CcEB6c1HUrN4jOOL1+bKYn44L0
pMFOlrI2LEOgZ2cyJlKlaOBkjOJxbNGp6pKZDMxT+Pgu0HVb73cE0aSozDm/LBQZ
56yWRVXLd/iADtXSNllzvkLJtxhuUpfNOWnGey7MnGMHIoxtCV/tufyjfnklWlVR
ja4P
=RTI0
-END PGP SIGNATURE-

Bug#1081745: ITP: rust-indieweb -- utilities for working with the IndieWeb

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-indieweb
  Version : 0.4.5
  Upstream Contact: Jacky Alciné 
* URL : https://indieweb.org/Rust#Library
* License : AGPL-3
  Programming Lang: Rust
  Description : utilities for working with the IndieWeb

 The indieweb library provides a collection of tools
 to work with the IndieWeb in your Rust applications:
  * IndieAuth supporting <https://indieauth.spec.indieweb.org/20201126/>
  * Webmention support <https://www.w3.org/TR/webmention/>

This package will be maintained in the collaborative debian section of
salsa, at <https://salsa.debian.org/debian/rust-indieweb>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmblgeoMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhx2UP/1MkhAZari/PzpaOoVteDfr/1/Cwub2sD1+jTOmI
nkHFaXoA4c/+hqaWGjYhuffCCkmAtsnhY3p/1O2efmi4J2wda9gaDLaRh8C9zIFH
JmQL3Ey0IRk4odOAOKTUhWcXcBqVsKc9g0KSFbZ1Cl5VFtL41ZiVaO20LZa3nhtM
owtP8aN6ARx/Yd9PiiWDTsMYxpzTAsgS/0UmpJnoPFq4AWCmy5VvQbX5rJjjVRMS
5ztx5IhkPtaS34m50+9zFOdvDG7WwEsn/PUNMbxwv4aHH/quknfhun3MAF26CGeL
8fLITlseiuD77XK5K6B9TlHO5KveDAt82Pfp0UzlbHem5fKaO+5NH9vYWMzBxsoi
56la2XR7sES3AMF598jWPzfK+KOyrgkcBASNhbKNz9qibcgx9Uj8r+Yy9Y1iJGx4
Y3PRL0dO0vZMCyLi7t27A3RNz9vD0BOKrwe8VsBrRiWJsRKkENUfA620pMIdQZwm
bJFFraJtbbrg0IUDDc6hXCF7nbp6N75BE26U7vZCHvmbnmTzwF1imyEplL2NMbVI
YBAh6a19eMgKMXQGiYzgYeanDXfECf5vKAP8/nJBCzFvQ1kyWgDFrM9Bps0JtM4X
SXcDCCl6C1Tf5NsRj/24XohqI8ejtp+4vwS3Q91Su9GExbH5POkThjzDTrSVb+Qm
TN2V
=hu5f
-END PGP SIGNATURE-

Bug#1081511: ITP: rust-yamux -- multiplexer over reliable, ordered connections

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-yamux
  Version : 0.13.3
  Upstream Contact: Parity Technologies 
* URL : https://github.com/paritytech/yamux
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : multiplexer over reliable, ordered connections

 Yamux is a stream multiplexer
 over reliable, ordered connections such as TCP/IP.

This package is needed for rust-libp2p (bug#1059908).
It will be maintained in the collaborative debian section of Salsa, at
<https://salsa.debian.org/debian/rust-yamux>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbisKoMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhKXIP/3Qql3BvS7iBaTIMOUqiv0yxBFOQH2eyl6+Guxus
gjCLF0fcST7g6Is2XsWsiuFAwKrICx0zTQA4KbJTyXzxN8MZdoOC8pvzlHlLcrBu
oJvtSF6jN0BA23XVoG9wFdbapIpBtnBZcE7BvXzlQTPkkE2qxor7LVvgde2YS9pZ
NHle5guPu1nhKf7jtSeqP0jg+wk19JqQlJExrDyM3P+0/BFDQlNMP6kbH5iWMgPG
MDVRrdxq4b8HqV5mZBgOoA4qlp1Fr/0lQoZX+v8NsAgtlnQRWduMScMM6TWMZjOZ
53avF1apsdGzCPXv5+/6Kdv0MRdPMJ2Lk97RKftaBn3CJTceppl8wQoca+NZwJAH
GAfoJDAMNmWbwszF2YMnUpjcrq6deO1jj3Wc0o/YIpMU2Qv/PBVZ0s2vqn6p/409
mSqTmsjft9IHMBKqf+tGmOX3dkkBU8gtUVSHLqWNfyjLNb/t2/5bK7tU6mnw0sB1
AMotGlI0quweLvyZWZMmDeTeFyB4wZQ3+/HgmlJnqHIOvGmur5uQaX45LIG7NkpI
9n2k2889sHdUGQAs0BdTfd3Pc48BglNrIgbYHE5ERkMJhvLwPorWbqajaQVhZXaM
rVLsRTFhKpkexoFuDaOosiWrP8QCza3qHIYBx3X+GNFmPKicd5pac/Al8XxQrASH
M76w
=Yris
-END PGP SIGNATURE-

Bug#1081507: feature bilock broken: requires patched-away feature unstable

[Jonas Smedegaard]

Package: librust-futures-util-dev
Version: 0.3.30-1
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The feature bilock depend on feature unstable which is patcjed away.
Apparently the patched away feature depends on similar feature for
several related crates, which are *not* patched away.

Please fix feature bilock, by dropping/reducing the patch.
While at it, please consider enabling bilock and unstable for the crate
futures as well - those features seem tightly related.

If unstable was patched away due to requiring nightly rust, then I
suspect those related packages should be patched as well.

Also, please document (more clearly) the purpose of patches, e.g. using
DEP-3 patch headers.

 - Jonas

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbilYkMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhnjYP/Rirvm3SNwEgiuLbrizk3n6MWfixTnG2ykBfZPBX
7Ogy78XpK53oDt6A+hTcyZEuUZNN4WInnvWLwT4u9DqV1vUDrj4j17GIesRyik+E
ddMq/LxYlSYfcBcuZCPwBxQi6Amd1rorxBu7Eae1cRX/GC2J9Tt6wH18hhp3Bbpl
9TK7yUxcVrYvY7EFQ5sFKHdZdUFRXw4z172+MEMf75aNgleH7d03ebk5zjVXf1/M
39LmtiYF1X6vViy/fidlTVedsI90CdSxMFigHysUagINujbuu7YZaqmuZK97sqww
JLrURLsrGNksZiMk2LcjdivxCNxjd16q5sTrxBHc9/qe4v5mceqI7VWLT5P+tEF2
l+GP7ljm7vFV/RAo5CawaefrSpuKEOgEh3Qb44R/XyhwV8q4pHHKZFOgqwSKEMGl
d9STYxLcf676EbPdMhqyTaFvn/4C+NfsL8QcpQXF5yIIcSbpqmDRZb9dCeNR4guW
JuhdmaJDmoR9cSxodUCriz7wrcT9q/7e1basx9deKLK0JgYqd9k0fFAVi34JZ4u1
F+dKwTURYLho1sNh+OOFkJsKs7v7Zi7R+lj5Vbr5PFaLE/1OdsFXWgy+mOA/xXSL
xCi8AW70fDFKbJILShyDyVKxKogc7e2dEBEuONlGJ1Us9Ovi1FBY3OCa9mPMBgbW
7maq
=kJD4
-END PGP SIGNATURE-

Bug#1081472: ITP: rust-clio -- library for parsing CLI file names

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-clio
  Version : 0.3.5
  Upstream Contact: AJ Bagwell 
* URL : https://github.com/aj-bagwell/clio
* License : Expat
  Programming Lang: Rust
  Description : library for parsing CLI file names

 clio is a rust library for parsing CLI file names.
 .
 It implements the standard unix conventions of when the file name is "-"
 then sending the data to stdin/stdout as appropriate.
 With the "clap-parse" feature it also adds a bunch of useful filters
 to validate paths from command line parameters,
 e.g. it exists or is/isn't a directory.

This package is needed by sdml (bug#1064145).
It will be maintained in the collaborative debian section of Salsa, at
<https://salsa.debian.org/debian/rust-clio>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbiAZwMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhtM8P/iHUhDOJ5fgJxLLQ6pBATcgubpkTedpgywbNXwqV
tbfTzXEK8jBFAFBQKeMy8WgRJYKhr1r1DixeSWNxfy8YZ/u3JOrzUVxKtsOnQQlu
PYtf4/1Y6SLA898XFEhHbW0DmCgvszOrCfgzVdDcNQD/552F37hf+64/e6VEa3Ac
3aI+QXxUz+4EdNiSZ5CwwLdqmh6/YLpivgqKp6wYgHrWdjMCz+CRpZPzZVxI0/0v
nO2osVuy/hPjqZrM5McdtZYiBVeUvOQ0i+NuzYNlG01o1pfVsxXu/8qerO4JW3md
2qgXRJZ2QVk6e9b+/lceTkz88XNNLr0i0wGBmLvjAEeTKXBzJ1nMJMt+bYi112rO
qXVpIO96AmLQ3Eao36yhJymgOtI0T+lGjsmw7a6wTWtXehC0rC6iNehQ2Yu7/CKy
6IYKaugYoK8uyEJlKt5ull8ssTTtlATTkMDP1JQptjK33fXV13bPM5EslLqABR+8
ZG/xlxlIWJC8TaJihIQjJ2Sd0+o5cFrWL0exPfaarYsV/n4mt9GAc9vBTVFKbdEY
M73/s9UAr8aKAQC7J4qr2osN827VLZAlQyaVMtRQgfZOB5yr2l88i8UwWYZOZEpr
mQSUlcShnoO+KXRqsGsjhIWaHYRse8+ATs4C69MfULBOeqpdv/UfMWFbBEIRoLew
eAak
=r8eG
-END PGP SIGNATURE-

Bug#1081349: ITP: rust-mail-send -- e-mail delivery library

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-mail-send
  Version : 0.4.9
  Upstream Contact: Stalwart Labs Ltd. 
* URL : https://github.com/stalwartlabs/mail-send
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : e-mail delivery library

 mail-send is a Rust library
 to build, sign and send e-mail messages via SMTP.

This package is needed for himalaya (bug#1000161).
It will be maintained in the collaborative debian section of Salsa, at
<https://salsa.debian.org/debian/rust-mail-send>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbgtNMMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEh4IwP/Ra29TvIcBndhtkT9YabxhpRhJz9HB3Lr/4CaxTZ
lgjG1eYBYGP1Ps7hz0QO+S56pwGFv4plOWni3VmoxIVKXBh4vwqEqXoLCswR3HfF
iKayHbB/My3Lw/60PlrMR9MZYJG5AVihOKkqR14FMQDMFiTGhUgQqonGChgNbf4x
gmehB0orckyXD5LyaO3tYqZ65PTKN7XUmQToprFbI7WJZ6tNDwv2HaQXQnr5LdaB
v5zXxwpOw92Br1cNfck0rMsu6Hw+crUUw6IWul4SRILti8fpIsU8VIPyzXV2Yhsy
i91XXojRNy5jfcEMk7trA785Ev568IPzA7p89qKyZoBHTjscvjfeMCoaXVz2uAv7
Zp2RwlVb3pyxibNO9NpHQaPF/XCs5U1KWOOwYeu1iAZGohYHUDuUSCyUr9slgRgb
QeXyraQv2IcyqQ9ubJKatXlmqUXS4psxeWAMeUfWpZC3oBzBZUyd/Raim2DyJN5E
gz0FpNP0/8MR88ngvJBUPYy3J6t6usInnuAAprGaXSPXu8IxbJMegntZfwIvnia4
pEAsJrqs7iPeIhSU3uqmbULRwipfx6uB1os4YHBrOJ4HrVBoSZW2dvrNKmJIrjTA
G2bZEt41f6BPN+c5jsATDF3WE7Os2nbyJ3ac/4YCbm4eeWCEQ0T+UETHo1AZddrg
AmI2
=6La7
-END PGP SIGNATURE-

Bug#1081344: ITP: rust-imap-client -- library to manage IMAP clients

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-imap-client
  Version : 0.1.4
  Upstream Contact: soywod 
* URL : https://github.com/soywod/imap-client
* License : Expat
  Programming Lang: Rust
  Description : library to manage IMAP clients

 imap-client is a Rust library to manage IMAP clients.

This package is needed for himalaya (bug#1000161).
It will be maintained in the collaborative debian section of Salsa, at
<https://salsa.debian.org/debian/rust-imap-client>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbgr34MHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEh1ucP/i9U9n0g1eLJknOxAJzVTXc/65WKrjwOUhsTSDZa
mvprAvquvHfVNUVLqnIVpNPKdqXxACHwQ23fIcDLXhVX+x8cxBn1c9uid4AExCfd
WzEgDOpHgl4I/6o1diNmBRe9OxuGlOl7hUFPq3Lb/vE8jTa1yxNejP1fIeTIGfC6
f8QhF1ozSNPj185DGZaY7LpJK2inCEtNWtJFJMZs1FTdU/yj2D56ZsFsDSkcXFMN
o6/+Y2mxJ6HM7YymPho0jb2hKaG95huVgtD/nf5RySReGl969Tpg4r3CGk1GXS66
K3IMa4xXj4QQSHoshPj2QFkblvrflLIm4mspB0HuP85/fN5qKBxDFEa6IzHme8Vg
FYUDOHwA8zmu0eot1PbVrTHHiocxxYiZ3+DjXWwE3n7N2jRLeof49hZ42JMUTc7B
ayUZ6pFjyDqS3dgX0SBLTUnwVIG2WMXMGb0kPREBcEXUMcqKwSeZyEPSRX6SPWoQ
bERa9t0OKhRuUjjtFbIYvHGgUgCmDP13FJ+5H706bLpfQ1CtYPhpXCfkQU/Jm2UM
sWD6mrwsMIGCg1Lb/nxh5OW0af+8Dtz/rYcE1K2TamP5Yj9IAjtNorSRMz6BBKV4
SdEj3D6AYWebTg0UEtyN8OqmKxm2hKgk+mX4Ybul11/ulIu3sS2fACF3FjNOkKxU
7DRw
=jvXa
-END PGP SIGNATURE-

Bug#1081335: ITP: rust-imap-next -- thin abstraction over IMAP protocol flows

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-imap-next
  Version : 0.2.0
  Upstream Contact: Damian Poddebniak 
* URL : https://github.com/duesee/imap-next
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : thin abstraction over IMAP protocol flows

 imap-next is a thin sans I/O abstraction
 over IMAP's distinct protocol flows.
 These are literal handling, AUTHENTICATE, and IDLE.

This package is needed for himalaya (bug#1000161).
It will be maintained in the collaborative debian section of Salsa, at
<https://salsa.debian.org/debian/rust-imap-next>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbgn2AMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEh+OUP/2d0y1dphsLoq/rZB1hnPS4u7ZWk0bPhznP2ENXd
PLm5w06FGytbXJL/TElHo8lkAosKLPOF0EbRxV+Z6jFbFmyJz+f/JRKbYDNEZSeB
eCo27f09wiYmfutjJKhtP3Bm27s/pzN5z9V0eKkft1nAwptQgef2ENJDG/B4y+Vd
TJMe+XhQYnBbYbBpnNthiywUGQ0/zKR2rKArKtjYctk2ZX2t6pA8tm6a5gmiwzGh
nLWU2TOQarwAVXsaiHn/gP5KupZ6mFazYpjYjHs7pIVWIFkj5/n/6uOZukHTD08k
r9U3PPuHvHYTi4u+PeoPco5gSeRzC3MrikiP6rrWVHzYeqwsj3Wpo84ico5wqtXY
Z1sX/ofe6tatHd8+cWaDVUIjKH1hLpx9uIWaO8RyKZU5XFXrHghlx4kGDbYqE2No
fDxc62CEz7M9og34HyUtlYgu3jQn0dVPtXgurCQxX1ea0tPT/TCUCbGFdvtzvoOP
lmTQ3MuCGN1Lwv1unyj1a5xloZjIOOIeGmw2yZb+3WpJ72l1q4UZBR+h+dtZrg1/
ijWX2Witn/ADWnoVw/J+SPbOK8cQNlbkt4azHDykKNI+bsz+ciERkAtXlOYAy3/V
8io6VCBKyyOVnTC/zha9FHr5qB4Uc1j7PvfaVAVGYcPvJgtWvZ0rR6vFEDc/oTHi
gCNw
=0Rkq
-END PGP SIGNATURE-

Bug#1081332: ITP: rust-smtp-proto -- SMTP protocol parser

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-smtp-proto
  Version : 0.1.5
  Upstream Contact: Stalwart Labs 
* URL : https://github.com/stalwartlabs/smtp-proto
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : SMTP protocol parser

 smtp-proto is a fast SMTP/LMTP parser for Rust
 that supports all registered SMTP service extensions.

This package is needed for himalaya (bug#1000161).
It will be maintained in the collaborative debian section of Salsa, at
<https://salsa.debian.org/debian/rust-smtp-proto>-

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbgm8kMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEh3QgP/1AMFQGoc+1uuIE6VNGST5yo3YLpKhRKDzHoV78L
MNBhxvG1MVYQLWiEFZFTPUHt6qpdGVUa1SdiZIEsiU7542RnyMvO9zdpvGiBHR3R
BOTupvsbeiytzekRHA/oUsdKwwklErzXf9MeaNGVgMuYD6QE9ihM73/+663JQTF7
R5w+vQ1ZLpmeZyuY6I21Sn2A0kdad0AQgwMStzq/WajY+n4kaxQOzdHmKRQq9Ni0
d0QJa38UAh3at7/pIHRbdvjGjzK2yzUlYwVTcnXXupRZ76FJTCtE8eAmenaSTbsZ
xMiGrGqCg1f1/Bi9fYvn/Pbx7vlOhKh60ZQUazbt9Rc4cjarXs3+efltNhKE3VJH
dynAyT7wT+NJUEnIwZx+zdpi9jHtHVfKYKyE+aHWzD4V9hGsWDtyEDCWl/xdvCPg
YcuoT/346tgC6DFrs+5nVg6ydJeIqQZFpEEhFFK0nalZKo6EiCKi5dbaWSZSU6D1
YVEmwJ4YCNQKSCv5iiAWkr4UcjB7h14JJlB7CfWuD6S8DJKNtw0sVZTH7zjv0467
THEjdyz5HfJZAaPwgFDBYOtcdwsqwxyEqofURIWEoCMob/QTR+YOnFjzYTW064p1
HU1Y8jUyKtfs8qic05bEX2P0Nmg0onm70hfgu6Kuw23721gR2K6a2Gwne7zQ6uiR
Lg2O
=JlwT
-END PGP SIGNATURE-

Bug#1081252: affects 1081252

[Jonas Smedegaard]

Quoting Jochen Sprickerhof (2024-09-10 18:13:02)
> * Jonas Smedegaard  [2024-09-10 17:26]:
> >Problem in that is that upstream do not use a Soname, so it would either
> >result in maintaining a slight fork, or involve convincing upstream to
> >care more strongly about backwards compatibility than they do now, and
> >maintain a Soname.
> 
> I would argue that it is worth doing that as it will probably happen 
> again.
> 
> >What I am exploring now (after the damage is done) is if the one other
> >package depending on ell can be patched to work with this change, and
> >then move on without Soname for now.
> >
> >I have now learned that a) I cannot trust upstream in only dropping
> >obsolete symbols, and b) even the removal of unused symbols cause
> >linking to fail.
> 
> How did you check that it is unused?

I looked in git log when the two symbols wer removed, knowing that they
were no longer needed for release 2.21.

> It does not look like to me:
> 
> $ mmdebstrap --variant=essential --include=iwd,binutils 
> --chrooted-customize-hook='objdump -CT /usr/libexec/iwd | grep 
> l_genl_attr_next' testing /dev/null
> [..]
>   DF *UND*  0000 (ELL_0.10)   l_genl_attr_next
 
That's a smart way to check.  I will sure use that in the future.

Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1081318: ITP: turtlefmt -- auto formatter for RDF Turtle

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: turtlefmt
  Version : 0.1.1
  Upstream Contact: 2022  Helsing GmbH
* URL : https://github.com/helsing-ai/turtlefmt
* License : Apache-2.0
  Programming Lang: Rust
  Description : auto formatter for RDF Turtle

 turtlefmt is an auto formatter for RDF Turtle.
 .
 For now, it...
  * validates that the file is valid
  * maintains consistent indentation and line jumps
  * normalises string and IRI escapes
to reduce their number as much as possible
  * enforces the use of `"` instead of `'` in literals
  * uses literals short notation for booleans, integers, decimals and doubles
when it keeps the lexical representation unchanged
  * uses `a` for `rdf:type` where possible
 .
 Resource Description Framework (RDF) is a standard model
 for data interchange on the Web.

This package with be maintained in the collaborative debian section of
Salsa, at <https://salsa.debian.org/debian/turtlefmt>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbgiY0MHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhYR4P/3KcRjPWSrCAozUkq96UOSxStreL2NB1rEOum0gD
vpakDnelSPSnS85S4CevgozmzpcxSK6gcuauJof1WkBSeepBZA0Vf1xcqHQeZaa+
5+YbN2KxfY3CcdOuXlh2+Ry8SpCpO5yiuyprsF0rzq4zgOjrJyABGXRW2Wl/CJAC
qa7L0poB85aLOSwD31owyPkDmXkJXDZYvQR5KZXFBCmfyii/lScxOozH7+JDK9Sr
Li84eok7T4rlKS1qGODcY+K5XxmUPUrULMi8AAbGdHfI9ZjIdzfBBcDaVU5BdslH
oNpp0tyHrtMawgoLqvKXhz3fezHDrSBwihUgmgKUvWlBto2b9R+ETYYN4zKqIb20
2nt+RgT1xkpaqpBCuxJmyzrqZdJC9XwRdPAtP0zvle5I/UUpLMlb7oFNQeHaTysZ
UbwfK24h9nEtoOaCfC9qQ7SShsUkX9HGVF7qs8I4am4qPZg6dpJT6z//qN5m4xP7
Ie1zZT3jf6smGBrLqDKSe4VoQHiaZ5ZvaJgs21upBv60pYl2n1AYm+yO3Ya2X0t6
pgrjoNsJgAaBvfxydCN34xHWHoDvTCE3dSlyQn0SjKhr5TuBPCZbsf51HrDymhU2
3t2WhlVLM/ZL9GH/vrh8ekuzhaHmoMVCY/f3kxKcvJ3i59y6fN9RjO4+0r4EToWu
E2SG
=8aZ/
-END PGP SIGNATURE-

Bug#1081252: affects 1081252

[Jonas Smedegaard]

Hi Jochen,

Quoting Jochen Sprickerhof (2024-09-10 11:38:04)
 from the ell (0.69-1) changelog:
> 
> [ Jonas Smedegaard ]
> * update symbols: drop 2 symbols, add 6 symbols
> 
> That sounds like you should bump the Soname and do a proper transition.

Yes, I should have (past tense), that is the ideal approach.

Problem in that is that upstream do not use a Soname, so it would either
result in maintaining a slight fork, or involve convincing upstream to
care more strongly about backwards compatibility than they do now, and
maintain a Soname.

What I am exploring now (after the damage is done) is if the one other
package depending on ell can be patched to work with this change, and
then move on without Soname for now.

I have now learned that a) I cannot trust upstream in only dropping
obsolete symbols, and b) even the removal of unused symbols cause
linking to fail.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1081265: does not support ELL 0.69

[Jonas Smedegaard]

Source: mptcpd
Version: 0.12-4
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Sorry, I messed up: libell dropped a few symbols with release 0.69, and
I sloppily assumed it was old obsolete ones unused anywhere - without
thoroughly checking that assumption.

Affected packages are iwd (maintained by me, and fixed upstream already
so required just a rebuild) and mptcpd, where I've reported the issue:
https://github.com/multipath-tcp/mptcpd/issues/302

Now, for the Debian use of libell, I see multiple ways forward now:

a) I revert libell to version 0.68 (i.e. with 0.69+really0.68)
   and halt progress on libell and iwd until mptcpd supports 0.69.
b) I revert libell to version 0.68 (i.e. with 0.69+really0.68)
   and reintroduce libell 0.69 under a new Debian-specific API,
   which can then enter unstable but can only migrate to testing
   when also supported by mptcpd.
c) Someone says "pfff, that's easy peasy to patch in mptcpd",
   releases mptcpd in Debian with that patch,
   and also forwards the fix upstream.

Anyone feel like the hero for doing c), saving me from rolling back the
mess I've caused here?

 - Jonas

- -BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbf6AcMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhHNoQAJURF8aEBP15UgB756woFFdNf2dox9AYssZepuS8
ImUty55pdZ6IjsPwpcUDeNKsyjWufZA4zjMNRYlehwMI2xYx9eYMvFqt87XET7mY
Tcj4Q1EsFcTqbUxLXrIC8VYEf2Z8BzWSRBaInPmyS85jvTmEu5S1icsa9WEYGMVC
yvczm6uZVf9Eap3oPs9Xvzpbz5bQVhM4TW/TPlQDkc1FNQtbq/Fdom/5zC92xNI4
n4Mt7rNHEfxOMy1T8obkfygVu6zpW8u+AnUPRejEOQPg+JFxWa5ABBsB69cd8P8Z
ZzivOYS08HzYRo6OYitJIaC3Oz1Lc3inIeaE2RBiGbx7nifmuEAK4ToMmuF5Pjd5
9HTciFa96G9F6lynHoxUcyHmLhy/CZLQIY7I+99UJZTYkwTqfCWtyW2hDpUd2rj0
ngByXpnq27tK7FJSTaWQ7f5zHx6aRdP4O5pSXh2gnzrSyzVwydR6GFyyVjLnWdwk
H+a0mWR6kFavmKPPOF2EV/IkGMxR7wfOHNEwfjKpk/En2bGWb+uQST9Qbn4GL9wi
KYOS2Zfeb/orcOk6nTC3lzda2ixqy0qYg0c1edNWWCVEDFUW2qA3QlNIN+FeZ51Z
x2vlTiFFpJHvS9LFhDdRHHqYJU7i7eaetejJw0Wtr1PUuSvsOUkpeN5kWvMYuyiJ
3yH9
=00Ml
- -END PGP SIGNATURE-

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbf6ccMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhDC0QAIgQFA31UeNU2Qv7+4iuZtny1kjmhibqGaOwUQxx
PHmrOrDsOMEopXQUq4MwmAup+H6hMkQUSFktV8WI0okzesmS37LuGERotxOmRQAN
LsjJzrRfHbp94Ki0cr3lE3QRVbQ+7VJIBBWyep5zT3LRBzOjcT86Lir4sH+gt6j5
o0ws+0b2WjgzHwGDx97oj00xTpICu/smaunzEI6CS6yw9WMsFFFzBSkxot+ZQMxI
BZeL5KhHFu1LOoXJZ27as5uxrw3Lp6BXRgOuSUMF3TeARc+A2FwCd16j1WIaEpwg
bpqfzvz6Phj3bX0zzOnSIZpYgRmICCflFhb99s44LsPjxjCFrxonohSKXNCIYSE0
kkHxYlJ/9RwxIfv5BMICLADwQAAyEYuxbr+TRUS6Pg/wpbMb7KsvRRUpgzQayMyi
F6Y2uTYO4Pi94fCDDyzizsfs2XD6xmbE6omvqBsRl92MWSkMzoQfI3zABUz1LohY
gKRZZUkl1k6ahENMuBGUia+p5xtpzyoHAdyr8qTrc/zFK7dGm0GOMfXlkHyk+lQe
RdJ38y5WiECF/RrZG9HO/tNWEXHJqq4MIwEzGlBGVsorr7YXrr97AJtin290vYfB
H6d7vhV3Fdc6LrkhIHIXKOpwNpbDSZRkp9zFnWs+CrICrXy1EIeExtCTmmr4RF/u
Y8QN
=1E2p
-END PGP SIGNATURE-

Bug#1081043: ITP: rust-notify-rust -- show desktop notifications

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-notify-rust
  Version : 4.11.1
  Upstream Contact: Hendrik Sollich 
* URL : https://github.com/hoodie/notify-rust
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : show desktop notifications

 notify-rust is a library for displaying desktop notifications.

This package is needed for himalaya (bug#1000161), iamb (bug#1061425)
and meli (bug#1001084).
It will be maintained in the collaborative Debian section of Salsa, at
<https://salsa.debian.org/debian/rust-notify-rust>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbcYKQMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhrF8P/2mbk14tvxFhLiKYQgVL0apXxJvM3q9i7vCKNP2E
UmIHGpqxAM5j8r+icXfNnIGucd6WazCKj/LTqDmg+LsTmtbH+BeapSJ+elgzW5zE
IH0xMfXDm/YX7CZ11T/9FNWksXuwGoT1iqHDrablHN4XLVyOZNtK4LvT1b5hi4eu
/cRE5DoF7mu+w6v3n4GhU8Ezum7eT1K5Kvd6QQf4E09PPP0lp/y1Pbco0Rxq4goE
MbemdxHvZ1gZiLzo9LRqn4Z8S89TvlLZNWkymiaaWscYRmSX7KcHnK7e34eQC/PN
sHU0LqKeGbugGlB5PHcPgW5hFWP4e9erOccMVmyWvNBzrt0vdMAv1sxoftlxpoxo
ZXYUr51Hn/7zul37hfZ6rOMaWl7u8KW34/tbkm1Slng6jZs6LtypzpQsdZat7CyV
n/v/qSW0SNgRWjM3Vu6+IeVa75zZfurtYmdIetvdISGr9KaI14ZsSnohFP6Zy16L
9G500fE92o4dnvGEID/vpuGJD/p5FPB0M8VJyWBA2qjysIQs4TXbGbYtSFmdIb7f
WOtksjYSJoMJ9qrqsn3L6Ewxn8r9szZrJRvCJ0S/ZcD5zouWOECtyYmFjIrAIWkH
ivsuaF7WiohxS65TsJGCgpZIR+FygBBlrLvvZi/gqOd2TAEupwICNR0AhjZbATUe
YWeU
=6E2/
-END PGP SIGNATURE-

Bug#1081036: ITP: rust-inquiry -- interactive prompts on terminals

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-inquiry
  Version : 0.6.2
  Upstream Contact: Mikael Mello 
* URL : https://github.com/mikaelmello/inquire
* License : Expat
  Programming Lang: Rust
  Description : interactive prompts on terminals

 inquire is a library for building interactive prompts on terminals.
 .
 It provides several different prompts
 in order to interactively ask the user for information via the CLI.
 With inquire, you can use:
  * Text to get text input from the user,
with _built-in autocompletion support
  * Editor to get longer text inputs
by opening a text editor for the user
  * DateSelect to get a date input from the user,
selected via an _interactive calendar
  * Select to ask the user to select one option from a given list
  * MultiSelect to ask the user
to select an arbitrary number of options from a given list
  * Confirm for simple yes/no confirmation prompts
  * CustomType for text prompts that you would like to parse
to a custom type, such as numbers or UUIDs
  * Password for secretive text prompts

This package is needed for himalaya (bug#1000161) and radicle
(bug#1073266).
It will be maintained in the collaborative Debian section of Salsa, at
<https://salsa.debian.org/debian/rust-inquire>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbcMOwMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEh7q8QAKmijrIoSe6K8hTDEJLzSef/oj+Bq5EglMPMr77N
VCk/zlillfoX3h2AM2TwIzl0xrKzoD4jg2r6BOiv+/B9gLGaistA9eTNoA8z0pEt
RD6pmKSVrJVIV/PB3tyLkA37me3JMXc5QiCR8KEO0MT9WxrrUoxV8e4TUwIOSy5N
/1lcGXmT/FzJAFmA9JC3LXJdBXxBAhGb1TMoQ3zY7JjcxFfCjs3jDiSBAPjkHHX1
80SCottet6eSVB22YzdU9DuDAIbBT0BIVQUVeQ0FndbbJwwd2Icq9duoP7EwMNH6
np91e4uM8hiA2ENyR1tN/tTvsaUDKDHRbv2kw25BCoRnIv6mF4n2waMVUSqR0/E1
DBknGijTZxHSC7pQBnlvnZuK7dXQKag08I9TykimX/3EeRNBeWDnd4tB/perztQA
bf8vL1Y6z/GYcuxiBvC49cElDgf++AVDfZI4l1QeWmgnTW72zttDX9WTY9gCKQLm
ICGPbqtFoR9iguKqTVGIBenOZVe6Xj2kt2GIHQTb80Eo8oWVeEnVHIsw3PMl2i5X
BHcbvmbPgqfhwFE4Qqtl2LpoQua9af+w+YZS5R4Q48G+ODJNUDPozX8l0jPJAs2C
dGPfDkqoonQEeckK+Ttrk9hv3rfw9IstD03K3wwhTLLAwW5kqi+DjVY0J5/ktxYF
IcYI
=A3t+
-END PGP SIGNATURE-

Bug#1031046: Backport to bookworm

[Jonas Smedegaard]

Quoting José Miguel Gonçalves (2024-09-06 18:38:28)
> On 06/09/24 17:27, Jonas Smedegaard wrote:
> > Please subscribe to our mailinglist and discuss more there, and please
> > join our Salsa team - see details athttps://wiki.debian.org/Teams/VoIP/
> 
> I'm a long time subscriber from your mailinglist... and I've just 
> applied for a Salsa account.

Nice. Then let's move the conversation to the mailinglist.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1081004: ITP: rust-async-fn-stream -- lightweight implementation of async-stream without macros

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-async-fn-stream
  Version : 0.2.2
  Upstream Contact: Dmitrii Kalianov 
* URL : https://github.com/dmitryvk/async-fn-stream
* License : Expat
  Programming Lang: Rust
  Description : lightweight implementation of async-stream without macros

 async-fn-stream is a version of async-stream without macros.
 This crate provides generic implementations of Stream trait.
 Stream is an asynchronous version of std::iter::Iterator.

This package is needed for meli (bug#1001084).
It will be maintained in the collaborative Debian section of Salsa, at
<https://salsa.debian.org/debian/rust-async-fn-stream>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbbMAgMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhDCUQAJKw/A5QwqLt1CAGizAXxhLpfFkMnCupsaljLYJt
ZolaJiamKTtf6xVclpSVWP/hcG5e4PJrx//r//ORHURv10Gftm1RHyxTD7r4dy8D
Oj3E4oE03HUtF/buWlHQfgc0nJvWpQG4ToWsaI8K2bCFnSO0zE/68UIhIvQPt5bz
Fdg0Wk210WdhZ7/UzOIriSPtHGF796tWhCqClMY23lkNGiXHOmIfURIZChmI6qKP
w4y+lgSDbCPm6nA/bQ6w2cyvoPQWg7gZKuatwCtyoZLb0s3SwMRUqxNoqNaADVDe
p4869b8tZNUXTFussm2LWCrGHcQGWDF0Zg4/6qVFEVv0v9hq26vVjxxzcqwieWap
vV8IE1OrorOj5gatE3Nck6B9qEwk6Z/jScyO8rqMseo1yeSdDSZ7n5L5oXRGGls4
CdPZ4FcIliQVHDBTp3jmH9ZVkOk845MpELzoSRGswaMM1OleS0xlXDMhalBXodUq
MEQqVQ2xcfS5eH6ZsmHHw4Tly0MmRifdQGKu+qWOcjcXBDbrk21/WzaaMiEe5l7I
XfSbZfXACC4uOXjskNaMQPxAC0c6oiICWm4JA/8nf9FxXfJ0cpKrvfQF5rhx9WlZ
xGVsb30cFdsJz8zQ9ymoLJJIn8tI0KG/DlwqmWeh3Sk7gyhgvxfG3Pkmf6FX86tU
1nL3
=uOOZ
-END PGP SIGNATURE-

Bug#1031046: Backport to bookworm

[Jonas Smedegaard]

Quoting José Miguel Gonçalves (2024-09-06 18:11:57)
> On 06/09/24 16:35, Jonas Smedegaard wrote:
> > I can do the task of releasing patches-applied updates, so you need not
> > be an official Debian developer to help.  All you need is dedication to
> > keep an eye on stable and oldstable branches of Debian, and the ability
> > to*try*  to apply patches.  If you notice a needed patch, try to apply
> > it, and that fails, then we are a team, and you can ask me to try as
> > well - and you can shout out to Debian developers at large on the
> > debian-devel mailinglist as well.
> >
> > This bugreport is about the lack of helping hands.
> 
> I could volunteer to help, but I could not give dedicate too much time 
> to it, because there is not much spare time on my side.

Great!

Noone in Debian has promised any specific amount of dedication - time
will tell if the actual time invested is adequate.


> I've no problems in patching, compiling, and making packages for Debian, 
> but would have problems to find the appropriate patches for old Asterisk 
> releases and would probably would not have the skills to test if the 
> patches are really doing what they are supposed to do.

Your skill set sounds perfectly helpful!


> If you are fine with those restrictions, please count with me... just 
> tell me were to start :-)

Please subscribe to our mailinglist and discuss more there, and please
join our Salsa team - see details at https://wiki.debian.org/Teams/VoIP/


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1031046: Backport to bookworm

[Jonas Smedegaard]

Quoting José Miguel Gonçalves (2024-09-06 16:37:28)
> I was thinking that it would be possible to go directly from unstable to 
> backports. Quoting from https://backports.debian.org/: "(In a few cases, 
> usually for security updates, backports are also created from the Debian 
> unstable distribution.)".

What makes sense to me is to interpret that passage as "...for cases
where the package in unstable is less buggy than the one in testing",
which does not fit here.

What makes sense to me is to pour all possible attention into getting
Asterisk acceptable for testing, and only *then* consider if there is
leftover energy to also offer a backport.

Hint hint: I expect to easily be able to handle the task of backporting
in addition to keeping Asterisk up-to-date in unstable.  What is needed
is someone volunteering the time to look after the Asterisk package that
is boringly sitting in stable or oldstable and occationally needing a
security patch applied.

I can do the task of releasing patches-applied updates, so you need not
be an official Debian developer to help.  All you need is dedication to
keep an eye on stable and oldstable branches of Debian, and the ability
to *try* to apply patches.  If you notice a needed patch, try to apply
it, and that fails, then we are a team, and you can ask me to try as
well - and you can shout out to Debian developers at large on the
debian-devel mailinglist as well.

This bugreport is about the lack of helping hands.

Please consider helping out.

Thanks for nice words about the work already done, but really what is
needed here is help.

Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1031046: Backport to bookworm

[Jonas Smedegaard]

Quoting José Miguel Gonçalves (2024-09-06 15:29:12)
> Thank you for your quick response.
> Please do not consider my questions as I was demanding anything.

I did not.

In fact, I appreciate knowing that others benefit from my maintenance
work, even if it only reaches unstable Debian.


> Going to a more specific question, are you considering packaging 
> Asterisk 20 for bookworm-backports?

bookworm-backports accepts only packages that has entered Debian
testing, so releasing to -backports is not possible before this very
bugreport about lack of adequate care also for long-term maintenance is
solved.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1077793: pandoc: Pandoc trying to use python2 for filter

[Jonas Smedegaard]

Quoting Scott Talbert (2024-09-06 15:32:17)
> On Fri, 6 Sep 2024, Kyle Robbertze wrote:
> 
> > On 02/09/2024 18:14, John G Macfarlane wrote:
> >> At the moment there is no issue on the upstream tracker.  It would need to 
> >> be properly discussed there before anything was done upstream.
> >
> > That is up to the maintainers of the package to decide.
> >
> >> 
> >> If Debian wants to patch their own version of pandoc to use python3, then 
> >> this would be a simple change to line 26 of 
> >> src/Text/Pandoc/Filters/JSON.hs.
> >
> > I am not familiar with Haskell or the Haskell team's packaging policies, so 
> > I 
> > am unable to provide a patch to the packaging without guidance.
> >
> > @Jonas you seem to be the most active maintainer recently. Do you have any 
> > pointers? I'm happy to do the work, just not sure where or how.
> 
> I'm nominally the human maintainer of src:haskell-pandoc.  I can take care 
> of this.

Please do, Scott. Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1031046: Backport to bookworm

[Jonas Smedegaard]

Hi José,

Quoting José Miguel Gonçalves (2024-09-06 13:14:26)
> I was wondering, what is the current maintenance status of Asterisk on 
> Debian?

Nothing has changed since my older responses in this bugreport, so
please read my other posts here and ask more specifically if there is
something you don't find covered there already.

> I see that there are packages published on unstable, but the current 
> version has a reported security vulnerability (CVE-2024-42365 
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078574>) since 
> August 12, that was still not addressed.

Yes, there are bugs filed against Asterisk.  Please go examine which of
those bugs you consider affecting your use of Asterisk.


> Is the goal to still maintain Asterisk packages in Debian or there is 
> lack of man-power for that?

As also reflected by my older resonses in this bugreport, the goal is to
maintain Asterisk packages in Debian, but having that goal is not
adequate exactly due to lack of man power: I have enough time to keep
Asterisk afloat for unstable, but lack the time to care for stable
releases of Debian.


> I'm using these packages since 2015 and I need to upgrade some servers 
> that I support form Asterisk 16 to 20 and I was wondering if could 
> continue to use Debian packages (even if I need to backport them from 
> unstable to bookworm) or if I need to go in other direction (find some 
> alternative Debian packaging, or compile/package it myself).

Whether you find the current level of care for Asterisk in Debian
superior or inferior to whatever support you can achieve elsewhere is
something I cannot really answer.  You do not *need* to go elsewhere, if
that is really what you are asking here.

Kind regards, and thanks for your interest in Debian and Asterisk,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1001084: ITP: meli -- terminal mail client

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2024-09-05 19:13:31)
> Hi Matthias,
> 
> Quoting Matthias Geiger (2024-09-05 17:21:55)
> > On Tue, 23 Jan 2024 19:46:47 +0100 Jonas Smedegaard  wrote:
> > > 0.8.5+20240101 draft 1 needs embedding 5 crates (3 missing, 2 ahead); 
> > > runs and seems to work from a brief test use.
> > >
> > > Main tasks are still to keep package up-to-date with upstream releases,
> > > and to package more of the crates currently embedded.
> > >
> > Hi Jonas,
> > are you still working on meli ? If so, is there any major blocker to get 
> > meli into the archive ?
> 
> Yes, I have simply been distracted by other exciting things lately.
> 
> Packaging is almost ready for release - will try finalize now.

Unfortunately more work is needed, and I could use some help with that:

Meli needs a patch to work with async-io v2.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1001084: ITP: meli -- terminal mail client

[Jonas Smedegaard]

Hi Matthias,

Quoting Matthias Geiger (2024-09-05 17:21:55)
> On Tue, 23 Jan 2024 19:46:47 +0100 Jonas Smedegaard  wrote:
> > 0.8.5+20240101 draft 1 needs embedding 5 crates (3 missing, 2 ahead); runs 
> > and seems to work from a brief test use.
> >
> > Main tasks are still to keep package up-to-date with upstream releases,
> > and to package more of the crates currently embedded.
> >
> Hi Jonas,
> are you still working on meli ? If so, is there any major blocker to get meli 
> into the archive ?

Yes, I have simply been distracted by other exciting things lately.

Packaging is almost ready for release - will try finalize now.

Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1080176: safe-vdash: rust-ratatui update to 0.28

[Jonas Smedegaard]

Quoting Blair Noctis (2024-08-31 08:22:55)
> I'm planning on an update of the rust-ratatui, from 0.25 to 0.28. Please 
> kindly
> adapt dependency on it in this package accordingly. Running cargo test with
> crates.io sourced ratatui 0.28 yielded no errors.

Great!

Please just go ahead, and (ideally, but we'll soon notice if not) bump
severity of this bugreport when the newer rust-ratatui enters unstable.

Thanks,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1080042: src:rust-hypothesis: upgrade derive_builder to 0.20

[Jonas Smedegaard]

Hi Daniel,

Quoting Daniel Kahn Gillmor (2024-08-30 04:45:57)
> Please update rust-hypothesis's dependency on the derive_builder crate
> from 0.12 to 0.20, as i've just updated derive_builder to 0.20 in debian
> unstable.
> 
> Despite the semver bump, derive_builder should be fully
> backward-compatible as far as the hypothesis crate is concerned.
> 
> The attached patch to the debian packaging should do what needs to be
> done.
> 
> Thanks for maintaining the hypothesis crate in debian!
> 
> Hoping this is useful,

Thanks for the thorough investigation, that is helpful indeed.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1080003: ITP: tree-sitter-sdml -- sdml grammar for the tree-sitter parser

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: tree-sitter-sdml
  Version : 0.3.2
  Upstream Contact: Simon Johnston 
* URL : https://github.com/sdm-lang/tree-sitter-sdml
* License : Apache-2.0
  Programming Lang: Rust, C, Python, JavaScript, Golang, Swift
  Description : sdml grammar for the tree-sitter parser

 tree-sitter-sdml is a tree-sitter grammar for SDML.
 .
 Tree-sitter is a parser generator and incremental parsing library.
 .
 The Simple Domain Modeling Language (SDML) is
 a small data-oriented language
 for constructing, documenting, and reasoning
 about a conceptual domain model.

This package is required for sdml (bug#1064145).
It will be maintained in the collaborative Debian section of Salsa, at
<https://salsa.debian.org/debian/tree-sitter-sdml>.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbQWZgMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhgsYP/0Kk20g1ouRzrgeO1dW8oWYfgql1AfuNk8mTr7pm
mFXAkz2RmABJJYgcg38AFxZtGNw527KjkkUlqbV8YGmAoPb+MnAFMFBbBG26m7BK
IfEqkYX/dAsxh1QlbZ8aXypRhhyzg+9di2+buhCuuoQNvW0B7QJXSBv890czngto
wY2JesygZPnLusDq0SmB7Lyuk7A1qpExaiO9hJLhBkrWX0FiExgMZUjSdFNiCeL3
v7RJN95xk07hXoMURwmCeGxObb79XQw3IXOyutFCclemOWxbqD7onYUDLALwjhnK
AHTw8uOrQAs6v6bdL7swz8l8Wne35EA+6q82ejiG4ctRxLdP/D8omtri/sKwvGd4
cCTYB/0qhSfCtUEY6FsOmVp+wGBG8J1P6zMyIZxik56WnHSXCJA7tYy4KmLFHzAB
7pgS8JF3ENeieY8AUu7YEEkefg8wBP4DqKOQj2KD0o3CFweW+fiP2GOjoUTjEpO9
iIVwnNFjvjaBzin6K8UOHmJNYMmKUx7r/98V/JrG/h8Co08gB0xhPcjFOn5tuHFb
EGwgt+eR92XoPFPr1YijPbBkR3LQ4OClfA2rprskqA0b0PklQj8C2crnNmyvDxi7
P21zq2pmNldy3Bdsr/MrGoL2OpS17JQnvE9+shuPGhWOt2aYjRBlFagB+391Sdzs
bg/H
=RVKb
-END PGP SIGNATURE-

Bug#732019: [pkg-uWSGI-devel] Bug#732019: PyPy plugin support‏ for uWSGI

[Jonas Smedegaard]

Quoting Alexandre Rossi (2024-08-28 11:38:22)
> Is there still interest in this?

I think it quite unteresting to offer support for PyPy3: That allows
experimenting with running Python-based services more lightweight.

Personally I am struggling with the ressource consumptions of my
matrix-synapse service, which is Twisted-based so might work with PyPy.

Even if not (it is a large and complex application after all), other
smaller projects might benefit.


> I have preliminary packaging but it requires more work regarding
> some issues.
> 
> The first one is that the libpypy-c.so filename is hardoced in the
> plugin, whereas it contains the version in Debian and there is no
> symlink (/usr/lib/x86_64-linux-gnu/libpypy3.9-c.so on my sid host).

Perhaps the fix is to simply provide a symlink with the package? - see
`man dh_link`.  Or am I missing a deeper problem here?


> The second one is that the very basic "Hello world" autopkgtest fails
> in the same way described ias an upstream bug[1]. There seems to exist
> other issues[2][3] with the pypy plugin upstream.
> 
> [1] https://github.com/unbit/uwsgi/issues/2342
> [2] https://github.com/unbit/uwsgi/issues/2436
> [3] https://github.com/unbit/uwsgi/issues/2534
> 
> It seems that the pypy plugin has never been ported to pypy3. Things
> do not seem to be moving upstream.

It is not surprising to me that the code may need some dusting off.

That was the case also with the move from python2 to python3.

And yes, the uWSGI project is in maintenance mode.  That means it is
helpful also for the wider community to get PyPy3 streamlined within
Debian, by collecting, testing, refining and (re)upstreaming patches.


> From the state of things, it does not seem reasonable to introduce
> this plugin into Debian.

You are doing volunteer work, so you are obviously free to pull out, or
to deprioritize.  It does not sound like a dead end, though, if you are
asking me...

Thanks for your efforts, regardless if you decide to continue,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1079845: Should vagrant-bindfs be removed from unstable?

[Jonas Meurer]

Control: severity -1 normal
Control: retitle -1 RM: vagrant-bindfs -- RoM; rc-buggy
Control: reassign -1 ftp.debian.org

Thanks Helmut for bringing this up.

Helmut Grohne wrote:

Source: vagrant-bindfs
Severity: serious
Justification: grab attention of maintainer
User: helm...@debian.org
Usertags: sidremove

Dear maintainer,

I suggest removing vagrant-bindfs from Debian for the following reasons:
  * It accumulated one RC-bug:
+ #953226: vagrant-bindfs: autopkgtest failure: cannot load such file -- 
/tmp/<...>/src/spec/vagrantfile_helper
  Last modified: 4 years

  * It is not part of bookworm or trixie and is not a key package.


As the former maintainer, I agree with your assessment and am in favor 
or removing vagrant-bindfs from unstable if nobody else steps up and 
takes over maintainership. I don't use the package any longer and 
certainly won't put any effort into maintaining it in the near future.


Kind regards
Jonas


This bug serves as a pre-removal warning. After one month, the bug will be
reassigned to ftp.debian.org to actually request removal of the package.

In case the package should be kept in unstable, please evaluate each of the
RC-bugs listed above.
  * If the bug is meant to prevent the package from entering testing or a stable
release, but this package should stay part of unstable, please add a
usertag:

user helm...@debian.org
usertags NNN + sidremove-ignore

  * If the bug no longer applies, please close it. If it is closed, check
whether the fixed version is correct and adjust if necessary.

  * Is the bug really release-critical? If not, please downgrade.

  * If the bug still applies, please send a status update at least once a year.

Once all of the mentioned RC bugs have been acted upon in one way or another,
please close this bug.

In case the package should be removed from unstable, you may reassign this
bug report:

 Control: severity -1 normal
 Control: retitle -1 RM: vagrant-bindfs -- RoM; rc-buggy
 Control: reassign -1 ftp.debian.org

Alternatively, you may wait a month and have it reassigned.

In case you disagree with the above, please downgrade this bug below RC
severity. Doing so will also prevent automatic reassignment.

Kind regards

A tool for automatically removing packages from unstable

This bug report has been automatically filed with little human intervention.
If the filing is unclear or in error, don't hesitate to contact
Helmut Grohne  for assistance.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1079801: Depends: librust-system-deps-6+default-dev but it is not installable

[Jonas Smedegaard]

Package: librust-rav1e-dev
Version: 0.7.1-4
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Fails to install:

Depends: librust-system-deps-6+default-dev but it is not installable

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbN+hEMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhwYcQAIYzleiqoPpwZ9n+ZBflORwu6tOqM98XbTgp6u7B
OxAaHxM4JaJHqLUdlevX+DtyvclHgFrKOWpvPSi9G8lwfDGi3UvAwK/dMJHPHsfS
D4DEnFsoIgIyVH8rx9EOpwnR233B/nGDPPlX2nfjAYy2NP/QsJMU+q2WPUqsqJ8D
cXbKUVsLjf0hoEngpB2WOJHH9qVVNMKtpllL3UwUGUa1b/qbMH9FlXx/kqIu7pj/
trqNKN1/mFYhZn5pgsYg2ZjooBA3oMQEKixFehpHB68DOg1u++addLycZPUcHAq3
WlRIRHyZccJoiUzy18gAdbzHioHENvgV2Msb+hn0/IT523+ohYn7RQFd0GQ9AO8K
CF+mQLH55USXw2DMFE6/Lx6ydZJKqX+98hxpzrbUvKT6hLCiqV/5oKFFKl5dTuIT
oRVG9J1RUavcltvkvx2QRxqFNSlgrcDdGgZKRtrjpOQRV4BJ01PyuElq7c+HE/kF
jQ1Gn2xowV4kwPxouvDLxcuWuEe8tbn1bxABMKiOvQstdUPUM3Ysx/qm//Sa2uWy
ON/CC0uxv72QVg32XNaevtuKVCPOAHcegDwWEMyX9K5FQO1PjPB1bcUNR0uwmZ0F
Pfvg91E5VG44GPug4iPOmNmlP8BRG0ki2e2zXYpvdnetVj0yWD0sRKEQNeArokUj
2Hlh
=y362
-END PGP SIGNATURE-

Bug#1078905: rust-wide: Autopkgtest failure on i386

[Jonas Smedegaard]

Quoting noisyc...@tutanota.com (2024-08-27 11:17:58)
> > Sorry, I still don't understand: If my patch effectively does nothing, then 
> > why do the tests now succeed when they failed without the patch applied?
> 
> What "fixed" the tests is the changes in d/tests/control, not the patch. 
> Tests passing is the expected behavior if the patch does nothing, because the 
> build is not prevented anyway and you are still testing with the debug 
> profile. The job of the patch is to prevent builds, not to make tests pass.
> 
> > Due to accidentally using wrong environment variable, it has even been 
> > tested that with the patch applied but without disabling optimization the 
> > build on i386 will fail, emitting the message from the patch.
> 
> Oh I see what's happening there, my bad. While I'm right (it's not 
> theoretical, I tested this on both amd64 and arm64 and it's a known fact 
> anyway) in saying that the `cfg` checks in build.rs apply to the build 
> machine, Debian's infra is not actually cross compiling, but running native 
> i386 code on amd64, thus the build is not effectively a cross build! I 
> acknowledge (and you saw that yourself anyway from the message in the build 
> failure) that your patch should work on Debian infra.
> 
> Where it will fail is if someone tries to actually cross compile rust-wide 
> for i386, e.g. if not building on amd64 or if building on amd64 but not 
> natively for i386. Since this is not done by default on Debian infra, my 
> patch is not strictly necessary. It may still be an improvement, to keep 
> consistency between native and cross builds, but not necessary.

Ahh, I understand now.  Thank you very much.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078905: rust-wide: Autopkgtest failure on i386

[Jonas Smedegaard]

Quoting noisyc...@tutanota.com (2024-08-27 10:14:40)
> Yes, I think you misunderstood. Your patch, as it is, will *always*
> build code for i386 when cross compiling, because the `cfg` check in
> build.rs applies to the build machine and the empty main function (via
> #[cfg(not(target_arch = "x86"))]) will always be compiled instead of
> the top one. CI succeeding is the expected behavior because the patch
> doesn't do anything when cross compiling.
> 
> The issue is the opposite: nothing will prevent from building unsound
> code when cross compiling (the default for i386 on Debian infra)
> because the topmost main function, which in your intentions would make
> i386 optimized builds fail, is never compiled during cross builds
> (again, #[cfg(target_arch = "x86")] is checked for the build machine,
> which in Debian's case is "x86_64", and not for the target machine.

Sorry, I still don't understand: If my patch effectively does nothing,
then why do the tests now succeed when they failed without the patch
applied?

Due to accidentally using wrong environment variable, it has even been
tested that with the patch applied but without disabling optimization,
the build on i386 will fail, emitting the message from the patch.

Sorry, but it seems to me that you are making a theoretic argument that
contradicts empirical evidence from Debian CI infrastructure.  Please,
if you still think that the patch as currently applied is somehow broken
then try spell it oout to me in even finer detail.

Thanks for your patience with me,


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1079754: ITP: scaphandre -- electric power/energy consumption monitoring agent

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: scaphandre
  Version : 1.0.0
  Upstream Contact: Benoit Petit 
* URL : https://github.com/hubblo-org/scaphandre
* License : Apache-2.0
  Programming Lang: Rust
  Description : electric power/energy consumption monitoring agent

 Scaphandre is a metrology agent
 dedicated to electric power and energy consumption metrics.
 The goal of the project is to permit to any company or individual
 to measure the power consumption of its tech services
 and get this data in a convenient form,
 sending it through any monitoring or data analysis toolchain.

This package will be maintained in the collaborative Debian section of
Salsa, at https://salsa.debian.org/debian/scaphandre

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbNfU8MHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhEF8P/3jp6H08YoVinTpSJHnvZlbY63kInz03pnfnJxFY
ItPvop1G8GPBrA7TwLl0hhfid1Xa3+A25lYAAnbFYuqXNkG2MKn9aRyDK1nfUiUa
iWhZ/JDFO4Oazuayt6H5tL2f/Foiol5qV7ia1fp4scrYIkAMNYjjhprlN4hUJfMw
m2xUh7KmUKDVjThuk1Lzc870sL4z9u/PU7a9lfbzu4SSBaVxkzcmwRUmsrhOXpfl
gDO8oWmeT8RX+88iIUFpIsAqD5AaYZ48RcxFRQEuXTwG5DWACHm+UdXqP7HT/pRD
oqfdA9qdAJ8pht94YVi5Z07ucaHrbd1fLEiiBU2VaS5fK29GnUHSxnI4ngLM5I/M
cuKhOftl06tXH2spgh1rZFlC9oFsnUZU9j7FvA3XlWPcc8W6atZPddRJ9wYI337T
gMkiRu67KxM7gY+J8sXX05aXhJMWjJLJHW6RBPLfW/3wVTdBBKsnYZEu5XlWes4U
EvnrZL5gp1Zzm4wmHRqsV7v0E8Sjlg9gGYVpLyFISWRL9AkXsBwOmYDj6vC/x6cv
FLESUq9Psk/Msj45IGx27Gwv/jZrnF2SkZLJCY+qWIxcfs90+JRCV/soDTqKT2EH
dRPHrUYAXHc+KDCOIrxZeDkaOyQmOw6D+D7PXNAULW8Ssoh7JMOqB/GMt5cBE6wi
nQcz
=X8ld
-END PGP SIGNATURE-

Bug#1078905: rust-wide: Autopkgtest failure on i386

[Jonas Smedegaard]

Quoting noisyc...@tutanota.com (2024-08-26 19:30:29)
> > Also, would be neat if the patch was improved to not fail but lower
> optimization level and emit a warning.
> 
> I liked the idea so I started playing around a bit. While I haven't
> found a way to achieve that yet (simply setting environment variables
> doesn't seem to work and there doesn't seem to be a facility for
> setting arbitrary rustflags from within build.rs) I found out that
> your patch will likely not work on Debian infra. Apparently, the `cfg`
> checks in build.rs (and build.rs only) apply to the build machine, not
> to the target, and on Debian's infra the i386 binaries are usually if
> not exclusively built on amd64 machines, so the empty main function
> will be built instead. I'm going to send you a MR to fix this.

Evidently an x86 CI run for rust-wide 0.7.28-3 succeeded, which seems to
contradict your findings above: Apparently my patch *does* work.  Or am
I misunderstanding something?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1079714: fails to install: chown: cannot access /usr/lib/netdata/plugins.d

[Jonas Smedegaard]

Package: netdata-core
Version: 1.47.0-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Installing netdata fails like this:

Setting up netdata-core (1.47.0-1) ...
chown: cannot access '/usr/lib/netdata/plugins.d': No such file or directory
dpkg: error processing package netdata-core (--configure):
 installed netdata-core package post-installation script subprocess returned 
error exit status 1
dpkg: dependency problems prevent configuration of netdata-plugins-bash:
 netdata-plugins-bash depends on netdata-core (>= 1.47.0-1); however:
  Package netdata-core is not configured yet.

If I manually create that directory, install fails like this:

Setting up netdata-core (1.47.0-1) ...
Failed to set capabilities on file '/usr/lib/netdata/plugins.d/apps.plugin': No 
such file or directory
chmod: cannot access '/usr/lib/netdata/plugins.d/apps.plugin': No such file or 
directory
dpkg: error processing package netdata-core (--configure):
 installed netdata-core package post-installation script subprocess returned 
error exit status 1
dpkg: dependency problems prevent configuration of netdata-plugins-bash:
 netdata-plugins-bash depends on netdata-core (>= 1.47.0-1); however:
  Package netdata-core is not configured yet.

If I manually create that directory as well, install succeeds.

Workaround therefore seems to be to run this command *before* installing
netdata:

sudo mkdir --parents /usr/lib/netdata/plugins.d/apps.plugin

Kind regards,

 - Jonas

- -- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 
'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.9.10-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages netdata-core depends on:
ii  libc6  2.40-2
ii  libcap21:2.66-5
ii  libcap2-bin1:2.66-5
ii  libgcc-s1  14.2.0-3
ii  libjson-c5 0.17-1+b1
ii  liblz4-1   1.9.4-3
ii  libmnl01.0.5-2+b1
ii  libnetfilter-acct1 1.0.3-4+b1
ii  libpcre2-8-0   10.42-4+b1
ii  libsnappy1v5   1.2.1-1
ii  libssl3t64 3.3.1-7
ii  libstdc++6 14.2.0-3
ii  libsystemd0256.5-1
ii  libuuid1   2.40.2-7
ii  libuv1t64  1.48.0-5
ii  libyaml-0-20.2.5-1+b1
ii  libzstd1   1.5.6+dfsg-1
ii  passwd 1:4.16.0-4
ii  sysvinit-utils [lsb-base]  3.10-1
ii  zlib1g 1:1.3.dfsg+really1.3.1-1

Versions of packages netdata-core recommends:
ii  curl  8.9.1-2

Versions of packages netdata-core suggests:
pn  apcupsd 
ii  iproute26.10.0-2
pn  iw  
pn  lm-sensors  
pn  nc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbMwsYMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhNc4P/1GUTFXR9eZErHzsVbpcQs6ElwthwpMSRVblcfHu
sphLrSCLqXW/39X9ifh0nHUNnZxRyc4GBM0xQDIH4iVCUGO8lObqi4irEcCAGDye
tXHgEsf4Hhd2n+olxQkAxlt9iD/A5dLdYFpjQxnc88LYfUAoBCEH8j5sJcfk1Bxn
rULNLVWB1R78DehThYqEKkULL5EfDV/T53ffHUEpyWJXPuJ57yVGmKDqE7VgGcxm
2d9aLtg0E4o2ZmEtrtVGttkoVWFV1cn+EmmVSSwoVyqVM02PWEIHKwjOvT7W0vpt
vbvBlSkjbUDw/LFKYOXFcnteKvHGc5SHMyppapjDVCMgwwuHzuG89bQrzdVRDVsc
MYnVx/HdeEVq3UtyjcMmWOFii13zfzKlMFG9YFGfPHGw9MXm9gvL7k5Khq7ZMQiy
CbG8tTAfoBD/Bmhj+zHEgjHq9DHhGW0kOc/HOfMOCYVXkMSfKp6CV719ERdea55h
Ba2H8qiGjXHbddKCNP7K9jBObrvc1S4YdgzoQLBfjO387e3DZLYAnpVOZSXTiQ34
spd3DSPdo5asc6VZTx8k0QjmwF7R1CvyHwwdbvpxYn6GYFhWdC1yHgKXtm2s6TW9
l6mJD4tagNSjc/gtOa6VtRKjh+bSNkg9ef2eIJ4vt/DLrBXEZtOQeEBd3GJUVl3v
SlTX
=DUAb
-END PGP SIGNATURE-

Bug#1078905: rust-wide: Autopkgtest failure on i386

[Jonas Smedegaard]

Quoting noisyc...@tutanota.com (2024-08-26 19:30:29)
> > Also, would be neat if the patch was improved to not fail but lower 
> > optimization level and emit a warning.
> 
> I liked the idea so I started playing around a bit. While I haven't
> found a way to achieve that yet (simply setting environment variables
> doesn't seem to work and there doesn't seem to be a facility for
> setting arbitrary rustflags from within build.rs) I found out that
> your patch will likely not work on Debian infra. Apparently, the `cfg`
> checks in build.rs (and build.rs only) apply to the build machine, not
> to the target, and on Debian's infra the i386 binaries are usually if
> not exclusively built on amd64 machines, so the empty main function
> will be built instead. I'm going to send you a MR to fix this.

Good catch!


> As for lowering the optimization level from within the build script,
> I'm not sure this is possible given what I wrote above. If I come up
> with something I'll send you a MR :-) And if you know a way to do it
> let me know!

Auto-adapting based on build-host rather that target-host is still
helpful for upstream consideration, even if it doesn't cover Debian
needs.


> > It would be helpful if you could test lower optimization levels than
> > the aggressive default might succeed.
> 
> This is zero by the way, any optimization level greater than zero
> builds unsound code and fails tests.

Thanks for checking!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078905: rust-wide: Autopkgtest failure on i386

[Jonas Smedegaard]

[resend Cc'ing NoisyCoil]

Quoting Jonas Smedegaard (2024-08-26 16:12:55)
> Thanks a lot for your deeper analysis, NoisyCoil,
> 
> Quoting noisyc...@tutanota.com (2024-08-18 11:08:35)
> > Given that upstream has closed the bug as "can't fix" I guess there's
> > not much left to do other than removing the package from i386.
> 
> I disagree: What is failing is not building the project on i386, but
> building *optimized* on i386.
> 
> Also, since the package does not provide compiled code but source, we
> cannot really "remove the package from i386".
> 
> I have now added a patch that checks at end-user build time and fails if
> the optimizations enabled and the build is targeted x86 systems that
> lack SSE2 support.
> 
> I think that patch is generally usable, not only for Debian but also
> sensible for upstream to adopt.  I have made them aware, but obviously
> it is their choice if they deem such a patch too fringe for them to be
> burdened with maintaining.

By the way: It would be helpful if you could test lower optimization
levels than the aggressive default might succeed.

Also, would be neat if the patch was improved to not fail but lower
optimization level and emit a warning.  In case you are up for such
challenge :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078905: rust-wide: Autopkgtest failure on i386

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2024-08-26 16:12:55)
> Thanks a lot for your deeper analysis, NoisyCoil,
> 
> Quoting noisyc...@tutanota.com (2024-08-18 11:08:35)
> > Given that upstream has closed the bug as "can't fix" I guess there's
> > not much left to do other than removing the package from i386.
> 
> I disagree: What is failing is not building the project on i386, but
> building *optimized* on i386.
> 
> Also, since the package does not provide compiled code but source, we
> cannot really "remove the package from i386".
> 
> I have now added a patch that checks at end-user build time and fails if
> the optimizations enabled and the build is targeted x86 systems that
> lack SSE2 support.
> 
> I think that patch is generally usable, not only for Debian but also
> sensible for upstream to adopt.  I have made them aware, but obviously
> it is their choice if they deem such a patch too fringe for them to be
> burdened with maintaining.

By the way: It would be helpful if you could test lower optimization
levels than the aggressive default might succeed.

Also, would be neat if the patch was improved to not fail but lower
optimization level and emit a warning.  In case you are up for such
challenge :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078905: rust-wide: Autopkgtest failure on i386

[Jonas Smedegaard]

Thanks a lot for your deeper analysis, NoisyCoil,

Quoting noisyc...@tutanota.com (2024-08-18 11:08:35)
> Given that upstream has closed the bug as "can't fix" I guess there's
> not much left to do other than removing the package from i386.

I disagree: What is failing is not building the project on i386, but
building *optimized* on i386.

Also, since the package does not provide compiled code but source, we
cannot really "remove the package from i386".

I have now added a patch that checks at end-user build time and fails if
the optimizations enabled and the build is targeted x86 systems that
lack SSE2 support.

I think that patch is generally usable, not only for Debian but also
sensible for upstream to adopt.  I have made them aware, but obviously
it is their choice if they deem such a patch too fringe for them to be
burdened with maintaining.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1079368: [Pkg-rust-maintainers] Bug#1079368: please upgrade to v0.36

[Jonas Smedegaard]

Quoting Peter Michael Green (2024-08-25 16:36:28)
> 
> On 23/08/2024 17:10, Jonas Smedegaard wrote
> > Both oxigraph and rust-rio are ready in experimental now.
> Thanks, rust-quick-xml is now in sid, and I see oxigraph
> has been uploaded to unstable, can you also upload
> rust-rio?

Done.

Thanks again for the swift processing,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1079498: helvum: build against GNOME 47 crates

[Jonas Smedegaard]

Quoting Jeremy Bícha (2024-08-24 00:40:40)
> Source: helvum
> Version: 0.5.1+20240328-3
> Tags: ftbfs experimental patch
> X-Debbugs-CC: werdah...@riseup.net
> 
> In my followup email, I'm attaching patches for helvum to build
> against the new rust-gtk 0.9 stack, currently in Experimental. We'll
> be uploading the packages to Unstable soon which will then mean helvum
> will fail to build. I don't think there is a lot of benefit to
> uploading helvum to Experimental now but you can if you want.

Thanks!

I'll wait until it breaks and fix it then.

Patches much appreciated!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1079368: [Pkg-rust-maintainers] Bug#1079368: please upgrade to v0.36

[Jonas Smedegaard]

Quoting Peter Green (2024-08-23 02:05:29)
> > Please upgrade to, or separately provide, quick-xml branch v0.36.
> > 
> > Raising severity, since oxigraph needs the bugfixes, and is crippled by
> > being forced to patch to use an older branch.
> 
> The new version is in experimental.
> 
> I've started looking through the rdeps but it may take a bit of time.
> I belive at least two of the rdeps, oxigraph and rust-rio are yours,
> can you prepare updates for them.

Thanks for acting quickly on this.

Both oxigraph and rust-rio are ready in experimental now.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1079302: please provide feature avif-encoder

[Jonas Smedegaard]

Source: rust-image
Version: 0.24.7-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Debian packaging of the rust crate image involves a patch to remove the
feature "avif-encoder".  Probably that was done to avoid packaging crate
rav1e, but that crate is now available in Debian.

Please reduce patching to provide feature "avif-encoder".

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbHJ/EMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhoOgP/1qAdS8cwO/l5iYqzUGL4rZ1yW5fTj9whQmKLpm1
9VoK7LPJck6rnkoMxe+GJw19EV+frUcPH92S0zayzq3g1ZGYkhcVYIzKr9v2FfQ5
vl0//GqcAhZ9iWSISkl+nG10qdb/FjDpYgvl3h/AM5loQHnnbwM01l0MeFjGszdI
tsR/rSh3q/hUQ82Lii/oc9D9A+zLyPsFBiloZbUPf9yrwcvntCUa+hqQqe5t6OIh
MA+5zMB3HZWHTp2gj300K+nnjhJQYQg5nWkqO6WWC0fazenJ+jSCVr2rtyG+7GlQ
oN6dxF5PSc603JuRb8Hqofl93q8JZVbRzSX2H+YcJHreqz0rW7mKhoUCdRe4TisN
MXNjCXfPGHHiR4y6ICz3f1fKZUydZrXe8wv/YHWUw0f7d2Sy+Z0eJ+sRJHiGNZXr
Rqpx++kudBR96+EktoH2ALqujEgFAT6Cm2GL/qRg7cGtjIhnqicn2o2E5hzafG9Q
jayiPxyW6plKmrN5bAG8BRpBlcacfQxoWoURkDxC8GINBtP2x12SqHjEcKztVY8x
Yev3T0yV4gQLXgjgmFhhhkG4aKohyzThHJLFlnezOwOk6ewBz95F+5kK+mPT/Qy0
E++ZAE2gG7rnkO6X//Y9pXftL9gk2/PMbBzfmIutfQxxcA8GlyaUbppfctrlaoTV
8bia
=bNmG
-END PGP SIGNATURE-

Bug#1078544: ITP: uwsgi-apache2-mod -- apache2 modules for uWSGI

[Jonas Smedegaard]

Quoting Alexandre Rossi (2024-08-21 09:09:34)
> Now the question is, is this useful in the Debian archive?
> 
> Remember, there are 3 available apache2 modules for the uwsgi protocol:
> - mod-proxy-uwsgi (built from src:apache2, popcon?, I use it)
> - mod-uwsgi (built from src:uwsgi, popcon 101)
> - mod-ruwsgi (built from src:uwsgi popcon 7)

Popcon is at most 1897 (the score of uwsgi-core), i.e. a conservative
score for these alternatives of more than %5 of the preferred one.

That seems a significant number to me.


> I do not see any reason to use anything other than mod-proxy-uwsgi.
> 
> So my take on this is:
> 1) disable apache2 building in src:uwsgi
> 2) if someone complains, introduce this package in the archive
> 
> The alternative is to not wait for someone to complain.

Regardless of the userbase being arguably significant, I am ok with the
approach of trying to pull the plug on them, having a package ready if
someone provides good reasons for reviving them.

Will you try prepare dropping these alternatives?  I imagine that in
addition to removal of the code and the entries in the control file
(see my related draft commit in the wip branch), it requires adding an
entry in debian/NEWS.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI

[Jonas Smedegaard]

Hi Alexandre,

Quoting Alexandre Rossi (2024-08-21 08:59:12)
> > > > uwsgidecorators.py would make sense in this package but is not
> > > > provided by uwsgi-src. OK to add it?
> > > 
> > > Yes: Anything needed for plugin/module packages should be included in
> > > uwsgi-src package.
> > 
> > Waiting for an upload to uncomment uwsgidecorators.py stuff.
> 
> Done, and finished for what I wanted to do unless you have further comments.
> 
> https://salsa.debian.org/uwsgi-team/uwsgi-plugin-python

Great!

I'll have a look at it - hopefully later today...

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078989: misspelled language in package description: should be Punjabi

[Jonas Smedegaard]

Package: firefox-l10n-pa-in
Version: 129.0.1-1
Severity: minor
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package description (both one-line synopsis and longer text) describes
the covered language as "Panjabi", which reflects the pronounciation in
the native tongue, whereas the proper english spelling is "Punjabi".

See e.g. https://en.wikipedia.org/wiki/Punjabi_language first sentence.

 - Jonas

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbCJ2oMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhuOIP/iTE6p/WfTL+XcGyFpepGi9C+uBikpQ8nyf271PA
d/gD8bxTWf6aFbheMd3cqgcLJ3Rh3ibelz1jOqtFX4hQpRl7ZTMvCVIouzNmNgf+
4at4nbj4AvOZrjhkmim8q+/zkVlbuPdBUgKNoapsQs64Szka7Ut9es0UdcUbOmXf
zE/h7x1otgKoRKfblGmtR6hw2GiozlnWvydvtCyy2+zSnYMu+/Jb/k+MipDLzCrd
Kw6VQ/Du+yAUzXULWMsNl6YdzgdBBGv1oUjKnaw+rCifCqoxJyvDDaJXswyLsxLP
Z/BDZ9avj0KP5F7tkpXvJkT2vUbM+BwXW11xpML686AHCKuxaLtluRVEWfTiy4WK
UWnnULcXZmZIRli1jO5Pnh7or/nOIOw4uc8zEVOct6wEtN+FNZ9baSFendRTDscM
mbfCcaByiFsdK/f1IGam8qs1fWDLeAomK0VpRJYiA0Dvu3NvRJwMSi/JnGrSvwED
O2AxRzgsmrCeWjuGyFQEYMTk03mFQHQx0V8YIWdp2K8j+Kofrusy8mQ7VxdnFNDl
/50AMSRSwkGXAabeE1eVe4YyYRferrTs1SQV+di4/HwncUle6eN1AHEStIZx7hVO
6GuogHPSc0ojKXb8WaAfasm2KBZNbdKqEC04QHELc1waIJCk8CpD3qqLOZdfy7fS
+vSS
=+SP/
-END PGP SIGNATURE-

Bug#1078905: rust-wide: Autopkgtest failure on i386

[Jonas Smedegaard]

Quoting noisyc...@tutanota.com (2024-08-17 22:46:11)
> What are your thoughts on [...]

I have no useful thoughts on the parts I did not comment on.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078905: rust-wide: Autopkgtest failure on i386

[Jonas Smedegaard]

Quoting noisyc...@tutanota.com (2024-08-17 22:05:59)
> Debian's i386 rust target being compiled without SSE2 and thus having
> inconsistent floating point behavior

SSE2 creeping in is an obvious suspicion to me as well.

I disagree that this is irrelevant to involve upstream with.

Please consider sharing your thoughts with upstream - I am not of much
help.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078905: rust-wide: Autopkgtest failure on i386

[Jonas Smedegaard]

Control: forwarded -1 https://github.com/Lokathor/wide/issues/174
Control: found -1 0.7.27-1

Quoting NoisyCoil (2024-08-17 15:51:02)
> Autopkgtests for rust-wide v0.7.28-1 are failing on i386, thus
> preventing migration to testing of rust-wide and its new reverse
> dependencies (the only one I'm aware of being rust-tiny-dfr).

Unfortunately, upstream developers (when this was shared with them)
found this to not be a failure in the testsuite but revealing troubling
behaviour that, as I understand it, shouldn't be suppressed.

I am thus giving upstream some time to come up with a solution.  If you
have ideas, then please consider engaging at the upstream issue report.

Thanks for reporting,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI

[Jonas Smedegaard]

Quoting Alexandre Rossi (2024-08-12 09:58:59)
> Issues/questions:
>
> uwsgidecorators.py would make sense in this package but is not
> provided by uwsgi-src. OK to add it?

Yes: Anything needed for plugin/module packages should be included in
uwsgi-src package.


> My packaging only builds for the default python version. Should we
> plan for multiple python versions supported in sid? My view on this is
> to wait for the need to arise. If ok with this, src:uwsgi should
> probably clean out all the alternatives provided. You view on this?

I used to strongly favor offering each available version, but nowadays I
don't really care, so if you prefer to reduce to a single non-versioned
package then go ahead - but yes, then be careful to handle the migration
(personally I would find it simpler to *continue* with versioned
packages now that it has been established already, but I leave the
choice to you).


> greenlet should be restricted to some archs, looking into that and
> considering specific source package. Advice?

I recommend to use the same method that I have used.

For simpler tracking of only one arch-variability, see link-grammar:
https://salsa.debian.org/debian/link-grammar/-/blob/debian/latest/debian/rules

If you still find my approach bad, then I am curious to learn why -
perhaps that's easier to discuss in a live chat?


> Please bring up any other comment you might have.

You might consider adding support for pypy3, and close bug#732019.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1073786: ITP: rudof -- CLI tool to process RDF with ShEx, SHACL or DCTAP

[Jonas Smedegaard]

Release 0.1.10 succesfully builds as an unofficial draft package,
embedding 9 crates (8 missing, 1 outdated)
which needs to be packaged before this can officially enter Debian.
The built binary runs and works fine.

Main task now is to package the remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package:
Either build it yourself from source,
or if you want to test the binary that I've built
then tell by posting to this bugreport and I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/rdfsx/-/blob/debian/latest/debian/TODO

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1076420: uwsgi: move away from cdbs - status update

[Jonas Smedegaard]

Quoting Alexandre Rossi (2024-08-12 09:58:59)
> I'm there.
> 
> https://salsa.debian.org/uwsgi-team/uwsgi-plugin-python

Great!

[details snipped...]

Let's keep the topic of this bugreport to getting rid of CDBS: Please
file a separate bugreport about splitting off Python-related binary
packages.  Or better: file an ITP package and let's discuss details
there.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078508: rust-rustls - upcoming mio update

[Jonas Smedegaard]

Quoting Peter Michael Green (2024-08-11 18:27:52)
> Package: rust-rustls
> 
> I hope to update tokio in Debian to the latest version soon,
> tokio itself is not semver-breaking, but one of it's closely
> coupled dependencies mio is. The new versions of tokio,
> tokio-macros, mio and signal-hook-mio are now available
> in experimental.
> 
> The main rustls crate does not appear to use mio, but the
> rustls-examples subcrate does.
> 
> I was able to build the package successfully after
> bumping the debian and cargo dependencies on mio.

Sounds good to me: Please go ahead and release to unstable, I am ready
to do a quick update of rustls to match.

Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078342: pandoc: Memory leak when converting markdown files

[Jonas Smedegaard]

reassign 1078342 src:haskell-pandoc
found 1078342 3.1.3-2
tags 1078342 +upstream +patch

Quoting Tobias Bengfort (2024-08-09 20:39:46)
> I have a large markdown file (11M) that I cannot convert to epub because
> pandoc runs out of memory. As far as i can see, this has already been
> fixed upstream:
> https://github.com/jgm/pandoc/blob/main/changelog.md#pandoc-315-2023-07-07

Patch is here: https://github.com/jgm/pandoc/commit/8764027

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1078261: broken update-alternatives registrations lacking plugin name

[Jonas Smedegaard]

Package: uwsgi-plugin-mono
Version: 2.0.26-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The package uwsgi-plugin-mono registers alternatives without core name.

Since it is the only uwsgi plugin with this broken naming, it is not
causing practical problems, it arguably only looks weird.

When changed (e.g. as part of packaging this plugin from a separate
source package), some migration away from this oddity MUST be included.

 - Jonas

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAma13Y4MHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhoWwQAJPLrUuA0e1KqvgZZImQREbvP/mx7edJJn5ERrPy
xw8vWQrMrN+Yywpy9lAIznpew4JxZ/8gOSnUveHAnvD7+EPoirqjeVmYwhegCjeb
/jl8VuVe+lyEYEx4lpyqsrHIcw208hGHVUGhF4oxHusN74SujgRYmthgRdiTe65R
3m0yFGp2fSBusiNa5CATkpNB2t5YMJ4YWgyvZvjwqbQMyQlolwV3dUN3ZYY8lYPT
8E0Dy0ZiQFO9DlKZZefwmELujXjHd0nN/ycKyAdhPOFkTD+PEmOpJ874xnC37lB0
Pm7Qld9NEHXDX5kIrZVd2ZgSYfggqGKV9jE7gXlVxO032uMnkRv6innoFwjemwB/
pLZc3v8lT0cKbhh/gwdkU6ATKfwN0eKnZm1gSrYzzzbEdgv9eGFpzDWHkzKC5jtC
8ZyQA6ulwkW/Oky0Po0dIIt5jd83TsWw4g6v/btVIJBkYTFuhTwJUDgz1QoUzLTm
BAno/JSdCMh0fY/F3aujWIPpVpFl2ooMr8lTwlfcPWfSQuE0NMH2PBkx61tnXpeR
I+2H86C41wYykFiPilPR5jc20zFgur2x6bWRFDLXiH86kI4+0oTBeEktTj5n2AnN
SRW2rhvRqiJkjv0YmF30kJiu3le62/dep/bmqrRF601KES4hFO7QG3JgKrfiE88G
K4JC
=hay1
-END PGP SIGNATURE-

Bug#1076420: uwsgi: move away from cdbs - status update

[Jonas Smedegaard]

Quoting Alexandre Rossi (2024-08-08 18:14:20)
> Can you confirm the list of new src packages you think about?

I see no need for doing them all at once, and worry that it needlessly
complicates oversight - similar to your transition draft.

> src:uwsgi-plugin-python3
> building uwsgi-plugin-python3
> building python3-uwsgidecorators
> building uwsgi-plugin-asyncio-python3
> building uwsgi-plugin-gevent-python3
> building uwsgi-plugin-greenlet-python3
> building uwsgi-plugin-tornado-python3
[...]
> Please confirm or comment, and I'll give it a go for python.

The above looks good.  Please create that, and test (e.g. with debdiff)
that it produces same binary packages as now generated with src:uwsgi
we can release that.  No need to touch src:uwsgi at all for this work.

Ideally, the package should be done in as mainstream packaging style as
possible, and we might consider offering its continued mainteance to the
Python team.  If something in its packaging is sticking out and pose a
risk that the Python team will find it scary to adopt (regardless if
they in fact adopt it or if we offer it for adoption at all - merely the
principle of being totally streamlined or not) then we might consider
extending our dh_uwsgi to handle any warts there.

Then, when we are happy about the new addon package, we release it and
have it approved by ftpmasters.  We can then simplify src:uwsgi to no
longer generate those same binary packages, and then repeat the cycle
for each of the other involved libraries.

...or please do tell, if you think I am missing something and there is
some benefit in doing more at once.

Independently from the above work we can look at other atomic changes to
simplify packaging, where one very narrow change (especially when done
*after* the above) is letting go of cdbs.  You can see my work on
"atomifying" your draft in branch wip/simplify - it it still both
unfinished and untested, but gives an idea of the level of atomicity
that I find comfortable for understanding what is going on.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1076420: uwsgi: move away from cdbs - status update

[Jonas Smedegaard]

Quoting Alexandre Rossi (2024-08-07 20:18:52)
> Hi,
> 
> > Thanks for your work on migrating away from CDBS.  I have stared at it
> > many times, and know that it must have been quite a challenge.
> > 
> > Unfortunately, I don't like the changes. :-(
> 
> No problem with that I wanted to start the discussion constructively. The good
> news is that now I have a good idea of what's needed to do that.

Phew.  I am very happy and relieved that you look at it like that.

Also, sorry for my keeping silent for way too long on your posts.


> All this is currently implemented in GNU make syntax, so this is doable to
> move to debhelper and not introduce some helper script. I'll try to
> come up with something. However, I still think that the handling of the
> plugin build configuration would be easier to maintain with a more capable
> language than GNU make.

The alternative you didn't list which I prefer is to branch out to
interpreter-specific source packages depending on uwsgi-source and using
dh helpers tailored for each interpreter - same as has been done already
for php and a few others.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1076420: [pkg-uWSGI-devel] Bug#1076420: uwsgi: move away from cdbs - status update

[Jonas Smedegaard]

Hi Alexandre,

Quoting Alexandre Rossi (2024-08-05 12:13:45)
> Status update.
> 
> [x] Build uwsgi-core
> [x] Build plugins
> [x] Build apache2 modules
> [x] Skip build of plugins not available on specific archs
> [x] Generate uwsgi-abi substvar
> [ ] Correctly generate preinst/postrm maintscripts for plugin binary pkgs
> [x] Generate d/control descriptions substvars
> [x] Install systemd units and initscripts
> [x] Enable the build system to generate multiple flavours of plugins
> [ ] Lower the amount of binary packages and group plugins according to 
> their
> binary dependencies
> [x] Ensure debdiff output between cdbs .deb's and dh .deb's is expected
> [x] builds in clean chroot
> [ ] Provide an easy way to check arch deps against archive (rmadison)
> 
> Legend:
> [ ] not done
> [x] done
> 
> My work is available at:
> 
> https://salsa.debian.org/uwsgi-team/uwsgi/-/tree/drop-cdbs

Thanks for your work on migrating away from CDBS.  I have stared at it
many times, and know that it must have been quite a challenge.

Unfortunately, I don't like the changes. :-(

But wait! Hold on! When I received a similar response some years ago,
It totally blew away my passion for the project I was involved in, and
I turned my back on it. And when I revisited that email more than a year
later, I realized that I had misunderstood the point of the email - so
please don't make my mistake but try hear my out...

One problem is that you did the transition as one big git commit
(when the fixup patches assumably gets merged).  That makes the change
difficult to follow, in case it turns out that some corner case is not
working as intended, and there is a need to understand what was meant in
more details with each detail of the change.

The bigger problem, however, is that your transition replaces CDBS with
another even more unique chunk of code, written in Python that I will
not be comfortable maintaining.

I can only imagine that you have worked hard on this, and I am really
sorry that I cannot accept it.  Especially since I have had my attention
elsewhere and been silent here for some time now.

I will try now to identify the parts that I find sensible from your
large commit and isolate those multiple atomic commits.  Then we can
perhaps look at the remaining part that you reimplemented as a python
helper script, and see if either you can convince me to make sense of it
or it can be expressed differently in a way we both are comfortable
with.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1052119: autopkgtest in experimental: sometimes just fails for rust libraries with "crate directory not found"

[Jonas Smedegaard]

Quoting Reinhard Tartler (2024-08-05 15:05:42)
> > In Jonas' defence, it is everything but obvious on what exactly to
> > declare the Breaks relationships.
> 
> Sorry, I mean to write: "In Jonas' defense, it is absolutely NOT obvious".

No harm done - I even think that it is proper (british?) english:

I read "everything but obvious" as meaning "not obvious even if maybe
lots of other things".


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1052119: autopkgtest in experimental: sometimes just fails for rust libraries with "crate directory not found"

[Jonas Smedegaard]

Quoting Reinhard Tartler (2024-08-05 14:52:28)
> Matthias Geiger  writes:
> 
> > - From my limited observation this only happens in experimental for rust
> > crates. I don't know what causes this. The autopkgtest ran fine when I
> > built the packages before uploading.
> 
> I believe this problem is much more widespread in testing than
> experimental and is holding up the migration of tons of packages.
> 
> Let me illustrate an example that jochensp helped me understand on 
> #debian-release:
> 
> Consider 
> https://ci.debian.net/packages/r/rust-async-executor/testing/amd64/49994925/
>  
> Note that this test was triggered to test rust-async-executor 1.12.0-3 (!!)
> 
> Here, we see in the part "test rust-async-executor-1:@: preparing
> testbed" (one has to manually expand this, I didn't notice at first):
> 
>  31s The following packages have unmet dependencies:
>  31s  librust-async-lock-dev : Depends: librust-event-listener-2+default-dev
>  31s E: Unable to correct problems, you have held broken packages.
>  31s autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt 
> pinning. Retrying with using all packages from unstable
> 
> 
> So basically we have uninstallable dependencies. What is worse, however,
> is that the test infrastructure happily continues with installing
> dependencies, all from unstable, *including* the package that triggered
> this test:
> 
>  35s Get:166 http://deb.debian.org/debian unstable/main amd64 
> librust-async-executor-dev all 1.13.0-2 [20.0 kB]
> 
> Basically the infrastructure was asked to test one thing (i.e.,
> rust-async-executor 1.12.0-3), but ended up testing something different
> (i.e., librust-async-executor-dev_1.13.0-2), and then declaring the test
> failed because:
> 
> 
>  48s autopkgtest [05:08:04]: test rust-async-executor-1:@: 
> [---
>  49s crate directory not found: 
> /usr/share/cargo/registry/async-executor-1.12.0
>  49s autopkgtest [05:08:05]: test rust-async-executor-1:@: 
> ---]
> 
> 
> I note that this particular rust package did not specify the restriction
> "skip-not-installable":
> 
> https://sources.debian.org/src/rust-async-executor/1.12.0-3/debian/tests/control/#L12
> 
> Would we expect the package to be marked as "SKIPPED" if it had
> specified that restriction?
> 
> 
> 
> What's the likely cause of this mess is that the following packages
> (both maintained by Jonas) had major version upgrades:
> 
>  - https://tracker.debian.org/pkg/rust-async-channel  (1.9.0 --> 2.3.1)
>  - https://tracker.debian.org/pkg/rust-event-listener (2.5.3 --> 5.3.1)
> 
> In both cases, we would expect major API changes and thus breakage in
> downstream packages. In neither cases any Breaks were specified:
> 
>  - https://sources.debian.org/src/rust-async-channel/2.3.1-7/debian/control/
>  - https://sources.debian.org/src/rust-event-listener/5.3.1-6/debian/control/
> 
> In Jonas' defence, it is everything but obvious on what exactly to
> declare the Breaks relationships.
> 
> Can we somehow improve the autopkgtest output to give better diagnostics
> to make this bug less confusing and easier to action on?

It seems that at 
https://ci.debian.net/packages/r/rust-async-mutex/testing/riscv64/49981801/
something makes the tests depend on a bogus package "async-std" (notice
the lack of leading "librust-" and trailing "-dev".)  Or am I misreading
those error messages and they are mean "crate" when they say "package"?

Perhaps that's a clue to what concrete goes wrong?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#574565: should remove ssl-cert group at purge if unused, and maybe add user to group

[Jonas Smedegaard]

Quoting Stefan Fritsch (2024-08-04 11:32:42)
> Am 19.03.10 um 03:05 schrieb Jonas Smedegaard:
> > ssl-cert adds a group at install which is not removed again at purge.
> 
> I think the ssl-cert group is something that the local user may use for 
> certificate files or keys. So, in order to determine if the group is 
> unused, one would need to search all file systems for files with that 
> gid. This would take an excessive amount of time during purge. I think 
> it is better to leave the group untouched.
> 
> Closing the bug.

Thanks for looking into this ancient bugreport.

For the record, I have since been convinced by the reasoning, and agree
with closing this bugreport.

You might consider acting also on bug#621833, which is still open.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1073959: [Pkg-matrix-maintainers] Bug#1073959: happens the same way for me

[Jonas Smedegaard]

Quoting Russell Coker via Pkg-matrix-maintainers (2024-08-01 23:15:50)
> QT_QUICK_CONTROLS_STYLE=Universal nheko
> 
> Makes it work for me.  Where is the qml6-module-org-kde-breeze package?

Thanks, that sunds quite helpful.

My thoery is that something (other than nheko) on the affected systems
sets widget style to Breeze.

Please, any of you that experience this issue, (double-check if above
helps for you as well, and) check if it also works to unset the style,
like this:

  QT_QUICK_CONTROLS_STYLE= nheko

and/or check if your system has that variable defined, e.g. like this:

  echo $QT_QUICK_CONTROLS_STYLE

Another thing that might help is to look for the setting stored on file:

  grep -ri breeze /etc ~/.config

NB! No need to share the pile of "access denied" lines in output - only
eventual actual findings are relevant.


Thanks,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#866784: chromium: Build with system libsrtp

[Jonas Smedegaard]

Control: forwarded -1 https://github.com/cisco/libsrtp/issues/721
Control: affects -1 chromium

Quoting Soren Stoutner (2024-07-31 05:01:23)
> There is an upstream discussion about this with the libsrtp developers.
> 
> https://github.com/cisco/libsrtp/issues/721

Thanks for working on this, Søren.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1077617: will not be maintained in trixie: please migrate to ahash v0.8

[Jonas Smedegaard]

Source: rust-ahash-0.7
Version: 0.7.8-2
Severity: serious
X-Debbugs-Cc: rust-curs...@packages.debian.org, 
rust-cursive-c...@packages.debian.org, 
rust-rustpython-par...@packages.debian.org, rust-trac...@packages.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

ahash v0.7 is outdated and it is a burden to maintain several branches,
so I would prefer to drop it.

Please therefore, reverse dependencies, migrate to ahash v0.8.

If that turns out to be problematic, then please let's discuss here -
I am not totally against maintaining this package for longer if really
necessary.

 - Jonas

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmapA44MHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhR4AP/3PK2ZxpHB65BLNURuWSmVF6UUG5Fa5PHYVEeLmU
izagBQbIjdggMrJ2GW5RdhGRQxqnHKUCiFYmdTbVPI+1mHdejnJP5vuGv4d+5v24
RDDItO5f176xC3JhwuJlZYt3ZZJdZXrF4zlbmF31L3fXwWOchg7/P9piH/MSKte0
hRhy44/7CYELwT4YXcoJPqDG5kmU45Y8MpjSOX7Wqt0dliK1FU+6mEwrqmYdUQap
v5z0YT3hsaEoZ+miKUiiiUlnPppp/YkOyHKu8ihzBBfUZYC2iOGDEVwy/7l3czZd
rzD/nyFDS4KucgA7zsI4HNOWLVlLqfVXgSCpa+Rau1zM86MSq55kxhVzGDEUvSFg
11bylHBl844r1FUfOG+fWKz7LYqMJbPGBO/tAkESiKRGGD3Ug5ESfb0pQJcy9pIH
kQGWdd8iE2A2i1V2DJDVQDWAEGFJ9GTvUXhFa8ikRlO+0PzsLZW3pM3gUG+2cuQp
lXGsWe1rcyyG6MeEC9oA92u5apSd+f1FkOawi45WhWjcg1DSR7BvnHMRhQ9cpSYJ
PTrIawPjtMBLn/sv0ZdOttKQubyGCpERsy+GmfL/q9jQlfTjdb0bDbT4RUiP/VZP
TvrCvErHzOyx9Q+CPYxXygiUhKNISsSq4yKg1TRIXMc+EAI8riOiyto/kcRAw/Ux
H+4P
=WJJE
-END PGP SIGNATURE-

Bug#1077596: upstream changelog (NEWS) is missing

[Jonas Smedegaard]

Package: parlatype
Version: 4.2-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream source include a NEWS file.

Please include that as upstream changelog file.

 - Jonas

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmaouaIMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhFeMP/3abveK1UXGASB9fFk9lSjKD3n0OsM2AA+gWO3aW
wJoJwnQw88xGiBWKO5zhTfaS/kV5i4RD7VcIUxd7fFVe+rhJs6q5bXSPZlZpyAJU
Inr4K2hLM3TnCoW9P8mYbzf8gpYHp4GsIZzIBSPrsxcztFt8l2MODfKo0ddUaXEM
1dNbT4qE8TkBparLzGw/i/hVKJbIfs9bGnc3+DkxvF3uGWVQ+3/9TIhsBbEKrT+H
rYpWYcU/bKDPOdUoDx26OyZfWxGgkvv2MIK6ldA3nPWWsDIfUW7soCCK2HqG32XU
OlvuvS8FL7rL0kRYmgCb0ro2ihw5p8nMvRlcutOB+qbI6AvM2293yBbYUyT2MzeA
VES6d335gkCAwg0CZqAJ540YSGA7HDo0BDiWBGloucgFrD4I1fjq+JecNG1We8Zl
AwL8ZbJdid/1DznDHLAgxPo6awm42zMIkbgfPe8tVohpCy6FTQvtm3VpfQZc3O5P
wWSTdwmo+2D7H6JUSn2yYNkOLo+88BvTUZy2aljYYpzAnAGk6djpm6s98Nc9/wn7
/rQ5vwiBiHKmLAA5hXNUkjCxkyArGYFkrCwD0GMvIxP0mnpZQU+MhiuHWMZ8xLqM
Bbgq67pPEfKlISPRSalcUNax7EqNiZbWoR/fBt9fqcsesbx5cRR0uZxvLuP0rEB8
ucaa
=Kdp5
-END PGP SIGNATURE-

Bug#1077511: please compare against dfrs in long description

[Jonas Smedegaard]

Package: dysk
Version: 2.9.0-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have difficulty understanding the purpose of this package.
I do understand what is described in the long description, but what I am
missing is how "df but better" is not already covered by the package
dfrs.

Since the purpose of the long description is to aid the user in deciding
suitability of installing the package, I recommend to improve the long
description to compare not only against df but also dfrs.

Personally I installed the package, tried it out and read its manpage,
but still failed to find any benefit of dysk over dfrs, and a few
drawbacks (expansion of device paths, lack of highlighting critically
filled partitions, and argually needless use of box drawing characters),
so I cannot help suggest what concretely might be the wording.

Kind regards,

 - Jonas

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmanoloMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhQA8P/iJYsHid+4ciCyPcrIHb4OeHV8/YfXxp4MDahXp0
1LyF7JJAt+xEfF7S2svA/bcdZa8m8AwQq1BgGOQ6G6egn1mbvZtwpNNKwtt+lJxE
rEHRewvALzSwigROQitA2WKTOcnPaKWZxy/CHybEC8HJpQICVt7SasTrb1FEq8ZM
DUxnjwQK1+lqgB0bYdr73lgkKslBxbvYxXk/qqRJ8ooNOVT/gs+uRMk2KVcF3egf
fqsi0uobNnQCHEMLRDtYfaQ9kWGwZZ3BLI6Q0xIrp1pCEo4siVAaa99LMEawOUEr
cTAV1FAeWArjYsH4zsYBIuMpWhh4221zrKdcrS0jk45GzDCH3trQHyJf8ZbPjvLc
K/jMrG68LI5T/Br0eg/H4E+Xlqh6FIpJrhdNxg0gY38n1F3DTM7XTmmwGONG5Ule
nry9OgXKIlu7ARjojU/Uci2GOJMkv62Pua12gNNr2pxeZtOihXQtTrLWLOzKKl8V
B2TNriP9xVAQtfx1gfzBYCsLHm+XwqZPRTEjtcYVlAc6Q0KvrKgHyQ9T/DHke/s7
+Pl7rOWzaufulZQ6Phb8e4gQl6PB9yVhaOIVH09pDwsY1oKdYRlH8u9gDv2uhX9p
YPV85Y8Mq3kUfDd/E7WFX+jCT1jz7xYgy0NW1Bd7j5GFoAxMlVhbZwKcNfnNbVvr
OjOd
=D8n5
-END PGP SIGNATURE-

Bug#1077474: rust-async-channel: std feature fails autopkgtest on s290x

[Jonas Smedegaard]

Quoting Matthias Geiger (2024-07-29 10:51:41)
> On 29.07.24 10:37, Jonas Smedegaard wrote:
> > Control: 2.3.1-6

Whoops, meant to write "Control: found -1 2.3.1-6"

> > NB! Please make sure to include version when reporting bugs.
> >
> > Thanks for reporting,
> 
> Sorry, forgot to include the version.

For future sake (I've done it now), in case you didn't know: You can
add the version later, either as I did (wrongly) above, or using the
command-line script "bts" from the package "devscripts", like this:

  bts found 1077474 2.3.1-6

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1077474: rust-async-channel: std feature fails autopkgtest on s290x

[Jonas Smedegaard]

Control: 2.3.1-6

Quoting Matthias Geiger (2024-07-29 10:06:04)
> thanks for fixing async-channels autopkgtest on armel. However, the std
> feature on s390x still fails one test:
> 
> 218s
> 218s failures:
> 218s
> 218s  mpmc stdout 
> 218s thread 'mpmc' panicked at tests/bounded.rs:468:9:
> 218s assertion `left == right` failed
> 218s   left: 3
> 218s  right: 4
> 218s stack backtrace:
> 218s0: rust_begin_unwind
> 218s1: core::panicking::panic_fmt
> 218s2: core::panicking::assert_failed_inner
> 218s3: core::panicking::assert_failed
> 218s4: core::ops::function::FnOnce::call_once
> 218s note: Some details are omitted, run with `RUST_BACKTRACE=full` for a 
> verbose backtrace.
> 218s
> 218s
> 218s failures:
> 218s mpmc
> 218s
> 218s test result: FAILED. 21 passed; 1 failed; 0 ignored; 0 measured; 0 
> filtered out; finished in 3.54s
> 218s
> 218s error: test failed, to rerun pass `--test bounded`
> 218s autopkgtest [21:37:53]: test rust-async-channel-2:std: 
> ---]

This smells like an unstable test, as I am pretty sure nothing changed
since last test run.  I will try simply request a retry, and close if
this bugreport if that succeeds.

This looks related: https://github.com/smol-rs/async-channel/issues/78

NB! Please make sure to include version when reporting bugs.

Thanks for reporting,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1077321: please upgrade to v1

[Jonas Smedegaard]

Source: rust-zip
Version: 0.6.6-4
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade crate zip to, or separately provide, branch v1.

 - Jonas

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmamLdsMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhV6AP/12sqGXIjuqN/VV7ySh0ELJvUTCJBIomw6zroZpw
OvLyuMLjQHj3T7iOzISvShvWVGKxIVKnz44ZlhP3i8rdHb64R3i03xXqw9zjeldi
d2AoWYPl13m6JsJRtpHFaDr9XaKoF+qfVC4mUrix9Mq8fvWHY4xp+hDR7PmMSctt
gIKe3S5E1LJ/P2T2X/FKLqbMonedTIXn93hIQGKzGR3EjMKgzhbKq75sF9RNF39Q
/QAI1sr8Eojhyok1j5WkPpPmPXToijT7v/fW4VQF8F45in0ad0Cxe+MCJsbAvCU/
9PZZ8Nb0iYaLcsSriAtu/9KAXk20W9cLQ5TiGUrkc9tJk29uPNjPAjSFbceLYqLN
asdvzwJMYyci4LuZtVxsV6nEyuIqgLXE27WnhPUThFbJ6VQIc/2elsVnh1XOk5BG
nh7ehrh0vr3LRksNoHuvA27IhndaxzbizHv6APnx16Ya6O9tKAH2bDFQlOAisAV7
2ICEO2RWHgmXICi5RayLbfO5ltuv2o8deeZZTQB4Mdb17ahdWB8RZljLVdzOAq31
lqloDAH3tdgo0p79nF+TeWs/EKSm5Nz2lUIZRXyGZC2oZxhgQJaiHEAFnqUHq1k5
DWlJ5wBFtGxYzXawrtRu2WptR/QtSTdGeQc1V77xJkNKx4TQCcYt+FWEQmhqUaPU
zYBP
=LBGn
-END PGP SIGNATURE-

Bug#1077320: please upgrade to v0.13

[Jonas Smedegaard]

Source: rust-itertools
Version: 0.12.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade crate itertools to, or separately provide, branch v0.13.

 - Jonas

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmamLRYMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhz3cP/2AqsiZGK0m9AaAf9VQkRw+VqKILUH8GcgmtfhmM
CfUZsDf8AncsivCgk1TtqAC/dMZqxmtwTcUBcbGo8ORzvQvuXWR5/xDwaaZrfysq
wE+TzMVbuu0ucWjPJMMTFkeys9GShHEI/aI7am6MsIjrCxcaqKSOGmGT60Nvm4yE
aJcCXac7IFG47VM1nCm+mM7sSRUIni46f8gzxcSwJir+wJ0V8mntCC8MFArdJi2T
T6bk7M7Lui7MykbVchoZPE3mCS2wwZcsg3PRf3eudlJEXqnma68WdSTeUc8A/v/I
05ZnM3KVm03DnF//Ox1GzU1ahOSJV7B9wbn1O4i2H8cgQwcR2AHHAB1R/L87ZQzL
O+BWI4hg3ZSYNLs+OgyOdyU+sQO9azEJfxg8cPgR2TJDLyoA4Xw6BUpXBubDt5u2
YqG8X8mzceBG7kHySQFTAFuADD7ivLvu5Ma4j7XCVv5qhIK20VzK0Q+buOThIzb8
AzDBfXUYye3UUPZk4kOjDEUgLkIxk5ztReGXwYkeZbjE2YjhWCp1Il7RgMoF7136
kgFzUa9Rkff7HSmWPGEpXB9wXv69RBvCWvhvQPw6LuI4113IyB1TmoSBELMuiiHl
2XTDdU4pXmsm3do0rjz9EBGNT9MSe1wZjFWcJHxRcE0Rr0RGZmiQZ4SlxzMkf1Wg
Rvpc
=Ma54
-END PGP SIGNATURE-

Bug#1077318: please upgrade to v2

[Jonas Smedegaard]

Source: rust-minijinja
Version: 1.0.3-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade crate minijinja to, or separately provide, branch v2.

 - Jonas

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmamLHEMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhbDwP/AlNaXV4YIVGkUhxsHQXs9LuSZ/KreXsdXT3YKSJ
nhOOO20qHwYUfZok9YMY2NUKEURN03ZtEvkyJ2ZCi15G3KTD/+GY58H8OQyETFpF
fEc3ZPovBIt8RyM86Kl/bUnrRJk2hmnAs76PWPP2JUCaMOqEbeGL5UDug41lf9E8
q4fA+pAgZO66NCOPIeDrv5cZDbmnwiw652V9yx5TtHeDIXyHnWIg6i+AOyBgBL+5
D0IMl8y6zDQrNn94dmoeBETwPqiXy/HCJgb6CPeCtvnkUAqagQWiscjxPXg+g0tj
XhHH4VhM9HjanLuK2AFbYerV+1O219yyZPTGmRSETOoGMHC8s0g4/Zg6BKFu/2We
l4t9vADr3MFnnqXoYp4cnQKA/58mW6sgwJ9hoTwf/nwpmydcN5WXCeB7b9ARIsUj
sLCxccwS34FICWXsmRiujeJssajOS8vhtG+xzAvdZj0PNqpRxAVbNK7U9dEe7o5k
kduFhMZvmGUdLcCEuFU6fuZUlJ8jacAJRTjz09l56tNEnjaB17Q7rbAnGWi98Dwi
SMc88enDrSrpC365lDH+9QcT09ROlLVRs33fYoKG4GO6HCw60E8BI9drk1Xjq/t0
4ZxRTbQCqm10D3RZjA8+ISo3VrfwEzHUCS6Sfy5I7mrLEzqvqmIxWIMnXlcS0bGY
fydU
=LIzR
-END PGP SIGNATURE-

Bug#1064232: rust-axum: Failing autopkgtests

[Jonas Smedegaard]

Quoting Reinhard Tartler (2024-07-25 08:11:33)
> 
> > rust-axum is unable to migrate to Testing because its autopkgtests are
> > failing
> 
> 
> >> I wonder why you are investing so much time and aggravation into
> >> getting the tests to work in Debian?
> >
> > Rust packages in Debian often deviate from upstream, making it
> > particularly relevant for Debian to check as much of upstream test
> > coverage as possible.
> 
> This reasoning is sane, but I question whether it actually applies
> here. Evidently, upstream does not consider running tests in the
> individual crates of the workspace and isn't even accepting patches to
> correct rather obvious oversights here. I find it admiring that you
> decide to step up, and invest significant portions of your available
> time to do the additional work nevertheless.

Upstream targets a distribution (the distributed set of components at
crates.io) where each version of dependencies and reverse dependencies
are static. That's not the case for the Debian distribution.

> Please find a patch attached that should fix the remaining autopkgtest
> failures.

Thanks!

I had not even noticed that those were missing - I were fighting the
failure to compile autopkgtests due to a missing file.

> I do have to wonder though: src:rust-axum is already at the thirty-first
> revision. Are the autopkgtests passing on your computer? I wonder what
> can be done avoid needing that many uploads, causing avoidable load on
> the test machines and help unblocking other packages from their
> migration to testing faster.

Building is quite heavy for my local system, so often rely on the build
daemons for testing.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1076915: radicale: FTBFS: help2man error

[Jonas Smedegaard]

Quoting Santiago Vila (2024-07-24 14:34:33)
> forcemerge 1076863 1076939
> affects 1076863 + src:radicale
> thanks
> 
> El 24/7/24 a las 14:19, Jonas Smedegaard escribió:
> > This smells like a bug in dpkg - reported now as bug#1076939.
> 
> Oh, I had already reported that one earlier today, didn't notice
> they were in fact the same, so I'm force-merging them.
> 
> (In fact, I personally prefer reassign + affects over an additional
> bug + blocking, as it generates less bugs).

Makes sense. Thanks for pointing it out :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1076915: radicale: FTBFS: help2man error

[Jonas Smedegaard]

Control: blocked -1 by 1076939

Quoting Santiago Vila (2024-07-24 12:49:05)
> Package: src:radicale
> Version: 3.2.2-1
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> During a rebuild of all packages in unstable, your package failed to build:
[...]
> PATH="/<>/debian/tmp/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
>  PYTHONPATH="/<>/debian/tmp/usr/lib/python3.12/dist-packages" 
> help2man --name "a simple calendar server" --no-info --version-string="" 
> --output  debian/radicale.1  radicale || { 
> PATH="/<>/debian/tmp/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
>  PYTHONPATH="/<>/debian/tmp/usr/lib/python3.12/dist-packages"  
> radicale --help; false; }
> Option version-string requires an argument

The call to help2man has an empty version string.

This smells like a bug in dpkg - reported now as bug#1076939.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1076939: dpkg-dev: no longer resolves variable DEB_VERSION_UPSTREAM_REVISION in core make

[Jonas Smedegaard]

Package: dpkg-dev
Version: 1.22.8
Severity: important

Dear Maintainer,

It looks like recent changes to dpkg-dev affects a bunch of packages
that I maintain.

Concretely, the package radicale now fails to build, as it passes an
empty version number to help2man. This was reported as bug#1076915.
Seemingly related bug#1076568 made me try downgrade dpkg-dev, and
indeed with dpkg-dev 1.22.6 the variable DEB_VERSION_UPSTREAM_REVISION
again resolves correctly.

It looks like recent dpkg-dev offers variable expansion only inside
make rules, not for make code declares "at the core", outside of make
rules.

Many of the packages I maintain rely on the ability to resolve variables
also at the core of the makefile. I am not furiously against changing my
packaging patterns, but I imagine I am not the only one, so I guess such
change needs more care and documentation (or perhaps just pointing me to
the elaborate documentation that I have totally missed).

Kind regards,

 - Jonas

Bug#1064232: autopkgtest now pass

[Jonas Smedegaard]

Quoting Reinhard Tartler (2024-07-22 07:45:20)
> I'm taking the liberty to reopen this bug again, because
> it seems there are additional autopkgtest failures in the rust-axum crate:

Thanks!


> Jonas, given upstream's stance on rejecting the notion of even attempting to
> allow non-git checkouts to run the test-suites, in particular from the
> crates
> as published from crates.io (cf.
> https://github.com/tokio-rs/axum/issues/2599#issuecomment-1970630060), I
> wonder why you are investing so much time and aggravation into
> getting the tests to work in Debian?

Rust packages in Debian often deviate from upstream, making it
particularly relevant for Debian to check as much of upstream test
coverage as possible.

Packages maintained in the Rust team are relaxed regarding some
classes of test failures, raising the risk of missing problems early.

For these reasons, and because I am not strong in coding Rust, so I
fear situations where upstream may not be able to (or interested in)
helping out with Debian-specific issues, I find it relevant to check
most possible, *before* entering testing.  If e.g. a feature turns out
to cause problems, then I have the option of skipping that feature, but
that's not as easy if the feature has entered testing and some reverse
dependencies are depending on that.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1076642: RM: rust-isahc -- ROM; incompatible with and blocks transition of polling v3

[Jonas Smedegaard]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: rust-is...@packages.debian.org
Control: affects -1 + src:rust-isahc
User: ftp.debian@packages.debian.org
Usertags: remove

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi ftpmasters,

The package src:rust-isahc in unstable has no reverse dependencies,
is incompatible with rust-polling v3, and a related larger set of Rust
crates including smol v2, async-channel v2 and event-listener v5, and
currently blocks the transition of that set of crates.

src:rust-isahc in experimental is kept in the hope of patching together
the project, without needing the whole ecosystem to wait for that.

Please therefore drop src:rust-isahc from unstable.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmab4xwACgkQLHwxRsGg
ASHfwRAAo7mA3W42F/1L0pvTwxv+kUdhopPyqdG73T0SDQsK+R3FUT9plNhGfTZM
N1PTPYQVJIrNFJMofx+ZJexKCPQ2C4gv0Mzc7ssmIKYcYjz+2g2X++eUky1qQLqX
htoH90uAgJ9MWdJO6D2WVWj6BR8zgvLtXA/siYoA8Y0feRbJ16rZq87B5A5CYqL2
dcIvx/FNfZoNIkwEH/8VLLXfYibrGxqbfo3d6K4fQUFX1d+qMyfDnWmOIsVpj5Ib
Zlp7/t9OhMR0Z/BZk3bFFVqUTzDHDy4xoN7qieDHF8+eahgnHLwY/CB/+ijapcly
cGCya8lUioweDl7W55NouBj13mRqXPA9r3DQMl2FNmRSyQbAtLShq9m7x+8kJHlP
CRjypmiptrxv4SinDg54cFJ5uEydXihdEF/I+lZPycrtOAlaQmJSPHjIKgtLDTkG
i/SLuRY49hnmwqLaZZDzNofuC9HYVLNhGzbrtk5Zp2fjm0ouCOimX5M9aJ11sm09
/sd5/6pX4Y6dJS0YH+3HVj/3EWsS/OHsrecUin6R5LW8eFEBwfy44Z6HykzwEevM
NeQ1xX/LeJn9mqrGamWwTB3rogW+9ZvnjTaTXT9ApWByCqm9deFXyM5ePUSKS6WU
zsncUQjsBqYz64efWDnkmqMHTNZiEX1gD3Ljy8+7U4KLaa1rilw=
=d6vk
-END PGP SIGNATURE-

Bug#1057254: rust-ratatui: please upgrade to v0.24

[Jonas Smedegaard]

Feel free to release ratatui and sysinfo for unstable -
"my" packages are ready for those upgrades now.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1057254: rust-ratatui: please upgrade to v0.24

[Jonas Smedegaard]

Quoting Peter Michael Green (2024-07-08 19:43:04)
> > Please upgrade to, or separately provide, branch v0.24.
> 
> I've just uploaded ratatui 0.25 and tui-react 0.23 to experimental.
> 
> Can you prepare updates for btm and safe-vdash and tell me when
> you are ready for uploads to unstable?

safe-vdash is now ready in experimental.

btm is ready as well, but requires coordination with bug#1057254 which
currently is blocked by git-delta.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1075991: please upgrade to v0.30

[Jonas Smedegaard]

Quoting Peter Michael Green (2024-07-19 02:48:17)
>  > Please upgrade to, or separately provide, sysinfo branch v0.30.
> 
> I've uploaded the new version of rust-sysinfo to experimental.
> 
> There are four reverse dependencies,  btm, git-delta, 
> rust-process-viewer and rust-vergen.
> 
> rust-process-viewer and rust-vergen are rust-team packages:
> 
> rust-process-viewer already uses 0.30 upstream and is currently 
> downpatched in Debian.
> 
> rust-vergen has a new 8.x release that uses sysinfo 0.30, which I have 
> packaged
> and uploaded to experimental.
> 
> btm and git-delta are Jonas's packages. Jonas can you take a look at them
> and tell me when you are ready for an upload to unstable?

btm is now ready in experimental, but also bumps ratatui dependency, so
requires coordination with bug#1057254.

I have tried but failed to patch git-delta to support sysinfo v0.30 and
would appreciate help looking at that.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1064232: autopkgtest now pass

[Jonas Smedegaard]

Quoting Reinhard Tartler (2024-07-20 08:10:13)
> with the patch above, autopkgtest now passes for me. Find the buildlog
> attached.
> 
> If it helps you, I could upload as an NMU maybe later today or tomorrow.
> Either by disabling the tests or applying the patch above. Let me know your
> preference on how to proceed with this RC bug.

Thanks a lot for your help here!

No need for an NMU, I can issue a release now.

NB! If you can find time to look at bug#1076602, then that'll allow
enabling features in axum that are needed for a use case of mine.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#996464: ITP: atomic-data-rust -- graph database server to share Atomic Data on the web

[Jonas Smedegaard]

Release 0.38.0 succesfully builds as an unofficial draft package,
when embedding 64 crates (59 missing, 1 outdated, 4 ahead)
which needs to be packaged before this can officially enter Debian.
Runs but needs to point to external web assets until those are packaged.

Main tasks now are to package NodeJS parts of the package
and dependent npm packages for that,
and to continue package the remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package:
Either build it yourself from source,
or if you want to test the binary that I've built
then tell by posting to this bugreport and I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/atomic-data-rust/-/blob/debian/latest/debian/TODO

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1007940: ITP: matrix-conduit -- lighweight homeserver for the Matrix protocol

[Jonas Smedegaard]

Release 0.8.0 succesfully builds as an unofficial draft package,
when embedding 36 crates (20 missing, 1 broken, 2 outdated, 13 unreleased)
which needs to be packaged before this can officially enter Debian.
The built binary is untested.

Main task now is to package the remaining missing Rust crates,
and to test the built package.

Here's how you can help:

As user running Debian, you can test this draft package:
Either build it yourself from source,
or if you want to test the binary that I've built
then tell by posting to this bugreport and I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/matrix-team/matrix-conduit/-/blob/debian/latest/debian/TODO

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1064145: ITP: sdml -- CLI for Simple Domain Modeling Language

[Jonas Smedegaard]

Snapshot at 2024-06-28 of 0.2.10 succesfully builds
as an unofficial draft package,
when embedding 7 crates (6 missing, 1 outdated)
which needs to be packaged before this can officially enter Debian.
The built binary runs and works fine.

Main task now is to package the remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package:
Either build it yourself from source,
or if you want to test the binary that I've built
then tell by posting to this bugreport and I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/sdml/-/blob/debian/latest/debian/TODO

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#996464: ITP: atomic-data-rust -- graph database server to share Atomic Data on the web

[Jonas Smedegaard]

Release 0.38.0 succesfully builds as an unofficial draft package,
when embedding 6 crates (1 missing, 5 outdated)
which needs to be packaged before this can officially enter Debian.
Runs but needs to point to external web assets until those are packaged.

Main tasks now are to package NodeJS parts of the package
and dependent npm packages for that,
and to continue package the remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package:
Either build it yourself from source,
or if you want to test the binary that I've built
then tell by posting to this bugreport and I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/atomic-data-rust/-/blob/debian/latest/debian/TODO

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1024683: ITP: helix - efficient console-based modal text editor

[Jonas Smedegaard]

20.07 snapshot from 2024-07-17 succesfully builds
as an unofficial draft package,
when embedding 6 crates (1 missing, 5 outdated)
which needs to be packaged before this can officially enter Debian.
The built binary runs and works fine.

Main task now is to package the remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package:
Either build it yourself from source,
or if you want to test the binary that I've built
then tell by posting to this bugreport and I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/hx/-/blob/debian/latest/debian/TODO

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1073266: ITP: radicle -- P2P code platform Radicle

[Jonas Smedegaard]

Release 1.0.0-rc.10 snapshot from 2024-07-16 succesfully builds
as an unofficial draft package,
embedding 44 missing crates
which needs to be packaged before this can officially enter Debian.
The built binary runs and works fine.

Main task now is to package the remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package:
Either build it yourself from source,
or if you want to test the binary that I've built
then tell by posting to this bugreport and I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/radicle/-/blob/debian/latest/debian/TODO

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1073786: ITP: rdfsx -- CLI tool to process RDF with ShEx, SHACL or DCTAP

[Jonas Smedegaard]

Release 0.1.2 succesfully builds as an unofficial draft package,
embedding 5 crates (4 missing, 1 outdated)
which needs to be packaged before this can officially enter Debian.
The built binary runs and works fine.

Main task now is to package the remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package:
Either build it yourself from source,
or if you want to test the binary that I've built
then tell by posting to this bugreport and I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/rdfsx/-/blob/debian/latest/debian/TODO

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1062222: ITP: gooseberry -- CLI tool to generate a wiki from Hypothesis annotations

[Jonas Smedegaard]

Release 0.10.0 succesfully builds as an unofficial draft package,
embedding 10 crates (9 missing, 1 ahead)
which needs to be packaged before this can officially enter Debian.
The built binary runs and works fine.

Main task now is to package the remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package:
Either build it yourself from source,
or if you want to test the binary that I've built
then tell by posting to this bugreport and I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/gooseberry/-/blob/debian/latest/debian/TODO

 - Jonas

signature.asc
Description: signature