Re: Q: systemd-timer vs cron

[Christian Kastner]

On 2022-03-12 21:42, Michael Biebl wrote:
> - Teach cron about systemd timers and allow cron entries to be marked
> with meta data that tells cron that when run under systemd it should
> skip those entries.

On 2022-03-13 01:07, Simon McVittie wrote:
> If there was a way to flag system cron jobs with metadata that says
> "this is redundant when running under systemd",
[...]
> I personally think I've written those in preference order (best one first),
> but it's up to the cron implementors' tastes rather than mine.
Unless cron finds a new maintainer (#984736), I don't think either of
these are going to happen.

Best,
Christian

Re: Seeking consensus for some changes in adduser

[Marc Haber]

On Sat, 12 Mar 2022 14:41:35 -0500, Michael Stone 
wrote:
>On Fri, Mar 11, 2022 at 10:16:24PM +0100, Marc Haber wrote:
>>[^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]] is found 829
>>times in Debian, mostly in docs and comments, but also in a few live
>>scripts. I think that we still have some way to go until we get rid of
>>the dot notation in chown calls.
>
>It also has to be a variable; if it's "root.root" or such, it doesn't 
>matter.

It matters if coreutils will at some time remove the dot notation,
making chown root.root an error. And I surely hope that this is the
end of the road we're progressing on.

>And remember, there are existing real-world debian systems that have 
>users with dots (regardless of local adduser policy; think ldap/ad for 
>example) so these are already issues that either need to be fixed or 
>don't really matter.

Yes, they need to be fixed, but it's a different can of beer if we
cannot say "hey, you changed our default, so you get to keep the
pieces of what got broken" but have to say "oops".

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Q: systemd-timer vs cron

[Marc Haber]

On Sun, 13 Mar 2022 08:47:27 +0100, Christian Kastner 
wrote:
>Unless cron finds a new maintainer (#984736), I don't think either of
>these are going to happen.

This looks like we all should migrate over to systemd timers as soon
as possible for everything, leaving the burden of keeping cron alive
to those systemd-free distributions.

The anti-systemd faction in Debian is cordially invited to step in,
bring cron and cronie up to shape, before asking the rest of the
Distribution to stick with essential system software that has been
unmaintained for years.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Bug#1007196: ITP: fishui -- Cutefish Desktop Environment UIKit

[Arun Kumar Pariyar]

Package: wnpp
Severity: wishlist
Owner: Arun Kumar Pariyar 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name : fishui
Version : 0.8
Upstream Author : Arun Kumar Pariyar 
* URL : https://github.com/cutefishos/fishui
* License : GPL-3+
Programming Lang: C++
Description : Cutefish Desktop Environment UIKit

FishUI is a GUI library based on QQC2 (Qt Quick Controls 2).
.
This package is a part of Cutefish DE.



OpenPGP_0x4B542AF704F74516.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Q: systemd-timer vs cron

[Bastian Blank]

On Sun, Mar 13, 2022 at 11:06:46AM +0100, Marc Haber wrote:
> The anti-systemd faction in Debian is cordially invited to step in,
> bring cron and cronie up to shape, before asking the rest of the
> Distribution to stick with essential system software that has been
> unmaintained for years.

And in that case, they please generate cron files from systemd timer
units.

Bastian

-- 
Warp 7 -- It's a law we can live with.

Bug#1007198: ITP: librist -- Reliable Internet Stream Transport for reliable transmission of video over lossy networks

[Florian Ernst]

Package: wnpp
Severity: wishlist
Owner: Florian Ernst 
X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Multimedia Maintainers 


* Package name: librist
  Version : v0.2.6
  Upstream Author : VideoLAN and librist authors
* URL : https://code.videolan.org/rist/librist
* License : BSD 2-Clause "Simplified"
  Programming Lang: C (+ asm)
  Description : Reliable Internet Stream Transport for reliable 
transmission of video over lossy networks

Reliable Internet Stream Transport (RIST) is a transport protocol
designed for reliable transmission of video over lossy networks
(including the Internet) with low latency and high quality.
.
RIST is intended as a more reliable successor to Secure Reliable
Transport (SRT), and as an open alternative to proprietary commercial
options such as Zixi, VideoFlow, QVidium, and DVEO (Dozer).


The second paragraph also describes my motivation for packaging this,
with my newly-acquired SRT maintainer hat on. Further information about
RIST (and most of the description above) can be found at
, and
further language wrappers and application integration can be found at
.

FFmpeg as present in Bookworm or newer already allows building against
librist, hence a heads-up to the Debian Multimedia Maintainers. I will
send a patch for evaluating librist linking once the package hits the
archives.

Cheers,
Flo


signature.asc
Description: PGP signature

Re5: Unsuscribe please

[Rubén Tortosa]

⁣Obtener BlueMail para Android ​

En 13 mar. 2022 0:44, en 0:44, Debian Project Secretary - Kurt Roeckx 
 escribió:
>Hi,
>
>This is the first call for votes on the General Resolution about voting
>secrecy.
>
> Voting period starts  2022-03-13 00:00:00 UTC
> Votes must be received by 2022-03-26 23:59:59 UTC
>
>The following ballot is for voting on changing the resolution process.
>
>This vote is being conducted as required by the Debian Constitution.
>You may see the constitution at
>https://www.debian.org/devel/constitution.
>For voting questions or problems contact secret...@debian.org.
>
>The details of the general resolution can be found at:
>https://www.debian.org/vote/2022/vote_001
>
>Also, note that you can get a fresh ballot any time before the end of
>the vote by sending a signed mail to
>   bal...@vote.debian.org
>with the subject "gr_vote_secrecy".
>
>To vote you need to be a Debian Developer.
>
>HOW TO VOTE
>
>To cast a vote, it is necessary to send this ballot filled out to a
>dedicated e-mail address, in a signed message, as described below.
>The dedicated email address this ballot should be sent to is:
>
>  gr_vote_secr...@vote.debian.org
>
>The form you need to fill out is contained below in this
>message, marked with two lines containing the characters
>'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
>change the choice names.
>
>There are 4 choices in the form, which you may rank with numbers
>between
>1 and 4. In the brackets next to your preferred choice, place a 1.
>Place a 2 in the brackets next to your next choice. Continue until you
>reach your last choice. Do not enter a number smaller than 1 or larger
>than 4.
>
>You may skip numbers, leave some choices unranked, and rank options
>equally. Unranked choices are considered equally the least desired
>choices, and ranked below all ranked choices.
>
>To vote "no, no matter what", rank "None of the above" as more
>desirable
>than the unacceptable choices, or you may rank the "None of the above"
>choice and leave choices you consider unacceptable blank. (Note: if the
>"None of the above" choice is unranked, then it is equal to all other
>unranked choices, if any -- no special consideration is given to the
>"None of the above" choice by the voting software).
>
>Finally, mail the filled out ballot to:
>gr_vote_secr...@vote.debian.org.
>
>Don't worry about spacing of the columns or any quote characters (">")
>that your reply inserts.
>
>NOTE: The vote must be GPG signed (or PGP signed) with your key that is
>in the Debian keyring. You may, if you wish, choose to send a signed,
>encrypted ballot: use the vote key appended below for encryption.
>
>The voting software (Devotee) accepts mail that either contains only an
>unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
>(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
>
>
>VOTING SECRECY
>
>This is a non-secret vote. After the voting period is over the details
>on
>who voted what will be published. During the vote itself the only
>information that will be published is who voted.
>
>You can encrypt your message to the voting system to keep your vote
>secret
>until the end of the voting period. The software will also try to keep
>your vote secret and will encrypt the reply it sends to you.
>
>VOTING FORM
>
>- - -=-=-=-=-=- Don't Delete Anything Between These Lines
>=-=-=-=-=-=-=-=-
>6acf7f89-3eb2-492c-8715-98ae65b5f9d2
>[ ] Choice 1: Hide identities of Developers casting a particular vote
>[ ] Choice 2: Hide identities of Developers casting a particular vote
>and allow verification
>[ ] Choice 3: Reaffirm public voting
>[ ] Choice 4: None of the above
>- - -=-=-=-=-=- Don't Delete Anything Between These Lines
>=-=-=-=-=-=-=-=-
>
>--
>
>BALLOT OPTIONS
>
>
>Choice 1: Hide identities of Developers casting a particular vote
>=
>
>Rationale
>=
>
>During the vote for GR_2021_002, several developers said they were
>uncomfortable voting because under the process at that time, their name
>and ballot ranking would be public.
>A number of participants in the discussion believe that we would get
>election results that more accurately reflect the will of the
>developers
>if we do not make the name associated with a particular vote on the
>tally sheet public.
>Several people believed that the ranked votes without names attached
>would still be valuable public information.
>
>This proposal would treat all elections like DPL elections.
>At the same time it relaxes the requirement that the secretary must
>conduct a vote via email.  If the requirement for email voting is
>removed, then an experiment is planned at least with the belenios
>voting
>system [1]. belenios may provide better voter secrecy and an easier
>web-based voting system than our current email approach.
>If this proposal passes, adopting such

Re: Seeking consensus for some changes in adduser

[Ansgar]

On Sat, 2022-03-12 at 14:41 -0500, Michael Stone wrote:
> It also has to be a variable; if it's "root.root" or such, it doesn't
> matter.

But that could be confused with a user named "root.root" instead of
user "root" + group "root" as intended. So this would need to be
changed to use root:root as well.

(Not that I would recommend having a user with this name.)

Ansgar

Bug#1007202: ITP: solo1 -- Python module and CLI for SoloKeys Solo 1 devices

[Domenico Andreoli]

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

* Package name: solo1
  Version : 0.1.1
  Upstream Author : he...@solokeys.com
* URL : https://github.com/solokeys/solo1-cli
* License : Apache 2.0 and MIT
  Programming Lang: Python
  Description : Python module and CLI for SoloKeys Solo 1 devices

With this package you get a command-line interface to manage your
SoloKeys and a Python module to interface them with your applications.

Some of the operations you can do:

- set or change the PIN
- read the firmware version
- update the firmware
- wipe all your credentials
- verify whether your device is a Solo Secure or Solo Hacker

Re: Seeking consensus for some changes in adduser

[Michael Stone]

On Sun, Mar 13, 2022 at 11:09:24AM +0100, Marc Haber wrote:

On Sat, 12 Mar 2022 14:41:35 -0500, Michael Stone 
wrote:

And remember, there are existing real-world debian systems that have
users with dots (regardless of local adduser policy; think ldap/ad for
example) so these are already issues that either need to be fixed or
don't really matter.


Yes, they need to be fixed, but it's a different can of beer if we
cannot say "hey, you changed our default, so you get to keep the
pieces of what got broken" but have to say "oops".


I don't think we can say that now, unless we also say that all the tools 
we have for integrating with external directory services shouldn't be 
used, and also retroactively change the documentation for adduser.conf 
to say that you shouldn't use the characters that the man page says you 
can. In general debian doesn't just say "hey, you changed our default, 
so you get to keep the pieces of what got broken" for configurations 
documented as valid.

Re: Bug#1007202: ITP: solo1 -- Python module and CLI for SoloKeys Solo 1 devices

[Philip Rinn]

Hi Domenico,

it's already packaged, see: https://tracker.debian.org/pkg/solo-python.
I plan to transition it to the new upstream name soon.

Best regards
Philip


OpenPGP_signature
Description: OpenPGP digital signature

Re: Q: systemd-timer vs cron

[Christian Kastner]

On 2022-03-13 11:06, Marc Haber wrote:
> The anti-systemd faction in Debian is cordially invited to step in,
> bring cron and cronie up to shape, before asking the rest of the
> Distribution to stick with essential system software that has been
> unmaintained for years.

I don't think that's a very constructive line of argument. As a former
maintainer, it was evident that user crontabs (crontab -e) are still
very popular, as are some other perhaps niche features, and I've never
had the impression that anti-systemd has anything to do with it.

And in all fairness, I did invest a lot of time maintaining it over the
years before I stepped down recently. I spent hundreds of hours alone on
converting our fork of Vixie cron from source format 1.0 to 3.0 (the
cumulative 1.0 diff spanned more than two decades of changes) so that
our fork can more easily be compared and merged with other cron forks,
such as cronie.

I completed that task a while ago, but then lost all motivation to
continue further. The cron daemons all originate from the early 90s.
systemd timers, being newer, just seem like a much cleaner
implementation, and thus the way forward to me. I could no longer muster
the time or energy to work on something I wasn't happy with, so I
stepped down.

In my opinion, the way forward for cron would be for someone to adopt
cronie, carry over any Debian patches not already included or equivalent
(there aren't too many, last time I checked), and to make cronie the new
default cron daemon.

Best,
Christian

Re: Bug#1007202: ITP: solo1 -- Python module and CLI for SoloKeys Solo 1 devices

[Domenico Andreoli]

On Sun, Mar 13, 2022 at 05:55:19PM +0100, Philip Rinn wrote:
> Hi Domenico,

Hey Philip,

> 
> it's already packaged, see: https://tracker.debian.org/pkg/solo-python.

Excellent, one thing less in my TODO. Let's immediately close thin bug.

Thanks for packaging it.

> I plan to transition it to the new upstream name soon.

Now, wouldn't be nice to have the latest version uploaded to main and
the renamed alternative to NEW?

> 
> Best regards
> Philip

Thanks,
Domenico

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05

Re: Bug#1007202: ITP: solo1 -- Python module and CLI for SoloKeys Solo 1 devices

[Philip Rinn]

On 13.03.22 at 18:47, Domenico Andreoli wrote:

Now, wouldn't be nice to have the latest version uploaded to main and
the renamed alternative to NEW?


Absolutely, that's what I just did - at least the first part. Uploading it as 
solo1-cli will follow soon.

Best regards
Philip




OpenPGP_signature
Description: OpenPGP digital signature

Re: proposed MBF: packages still using source format 1.0

[Sean Whitton]

Hello Ian,

Thank you for the summary, which helped refresh my memory.

On Wed 09 Mar 2022 at 04:38PM GMT, Ian Jackson wrote:

> 1. Why is 1.0-without-diff not always worse than 3.0 (native) ?
>
> 1.0 native is sometimes better than 3.0 (native) because dpkg-source
> refuses to build a 3.0 native package with a Debian revision in its
> version number.
>
> This prohibition exists solely because of a doctrinal objection to
> native-format packages with Debian revisions.  There is no technical
> reason why this restriction could not be lifted.  I sometimes upload
> this way and I have never had anyone report problems[1] with it.
>
> IMO there is nothing wrong with native format packages with Debian
> revisions.  They work just fine.  For a small paockage, this is often
> a good choice, because it avoids dealing with patches at all.
>
> For anything but a small package, use of diffs is needed as a storage
> and distribution optimisation.

It it perhaps worth noting that this idea that native source package
formats cannot have Debian revisions is an idea found in dpkg, not in
Policy, which latter otherwise has quite a bit to say about native vs.
non-native.

> Changes not representable by diff is what Sean is talking about here:
>
>> Ian has some cases where something that is representable in git is not
>> representable using 3.0 (quilt) but is representable using 1.0.  I don't
>> have those cases to hand; Ian, could you summarise, please?
>
> Currently, I think diff cannot represent changes to symlinks.
> git can store symlinks and represent their targets, and changes to
> their targets.

So in this case 1.0-native is the only option.  And it would be a
downgrade to mess around with what git represents perfectly well just
for the sake of an output format.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: proposed MBF: packages still using source format 1.0

[Sean Whitton]

Hello,

On Wed 09 Mar 2022 at 05:15PM +01, Lucas Nussbaum wrote:

> On 09/03/22 at 08:52 -0700, Sean Whitton wrote:
>> On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote:
>> > Also, how would that work with packages that combine direct changes to
>> > upstream, and quilt for Debian-created patches?
>>
>> Could you expand?  I didn't think this category was one of the ones Russ
>> and I were talking about.
>
> My limited understanding of the landscape of git workflows is that a
> workflow that is quite popular among packages still using the 1.0 format
> is the one used by the Debian X strike force. Julien Cristau described
> it as follows when I asked about it on IRC:
>
> < jcristau> [...]  basically, for upstream patches we cherry-pick
> commits directly, and we use quilt for changes that aren't upstream

Ah right, thank you.  I wasn't really thinking of this case as being
about git workflows.  Are the repos patches-applied or
patches-unapplied?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Q: systemd-timer vs cron

[Paul Wise]

On Sun, 2022-03-13 at 18:02 +0100, Christian Kastner wrote:

> I don't think that's a very constructive line of argument. As a former
> maintainer, it was evident that user crontabs (crontab -e) are still
> very popular, as are some other perhaps niche features, and I've never
> had the impression that anti-systemd has anything to do with it.

As a systemd user who has a large user crontab I have to agree.

I'd like to migrate to systemd timers, but there are a few blockers:

The cron feature of sending the output via email by default isn't
possible to get easily with systemd timers or systemd-cron, unless you
modify every single timer to manually send email or use systemd-cron
and have every single timer fail.

Having everything in one file makes them more convenient to edit.

Being able to implicitly share environment variables between groups of
crontab lines is more convenient.

Figuring out if there native systemd equivalents for features I've
implemented manually, such as the lock and sleep times to ensure system
load isn't high due to running everything at once or disabling jobs
when the network isn't online.

Spending the time to migrate everything.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: proposed MBF: packages still using source format 1.0

[Sam Hartman]

> "Guillem" == Guillem Jover  writes:

Guillem> On Thu, 2022-03-10 at 12:09:14 -0700, Sam Hartman wrote:
>> You're trying to produce packages from CI builds or other
>> automation where you sometimes have native Debian revisions.
>> 
>> * you are producing a package where you have distinct upstream
>> and debian branches, and you cannot control the upstream version
>> number.  You want to do everything in git, and not have to deal
>> with quilt patches.  Say you don't even have any patches, but you
>> sometimes do produce new revisions simply for changes to debian
>> control files and the like.

Guillem> As I mentioned last time around, it has never been made
Guillem> clear why a different “revision”-separator character cannot
Guillem> be used here. (Perhaps out of doctrine? :)

Often that works.
It's kind of strange though to have to change revision characters
 depending on the releases.
For example I've been in situations
where  releases were built from tarballs and were not native, but
betas and other upstreams were built directly from git and thus were
native.
So some revisions had + as a revision character and some had dash.

But also, let's imagine it were doctrin.
Policy should decide that kind of doctrin not dpkg.

>> * You are trying to local (or downstream) builds of debian
>> packages that do have debian revision numbers.  You want to do
>> everything in git because honestly dealing with dscs is a PITA
>> and if you can avoid it you want to.  You need to produce dscs to
>> feed to sbuild, or mini-buildd or something.  But you just want
>> to do that easily from your git CI pipelines.
>> 
>> My frustrations with the number of hours I've lost because of
>> this doctrinal issue has caused me to come close to giving up on
>> Debian more than once.  Part of that is frustration around how
>> the change was handled and how concerns and use cases where not
>> considered and dismissed without consideration.  But part of that
>> is how I've had to hack around the isue in every downstream CI
>> environment where I took Debian packages and modified them.

Guillem> In this second scenario, you seem to be using .dsc in
Guillem> anger, when you don't really want to have to be using them
Guillem> at all. And when doing that you seem to have decided that
Guillem> using them in a way that makes our packaging stack more
Guillem> confusing, incoherent and error-prone is better, than say
Guillem> trying to get those other tools to avoid using the .dsc
Guillem> format at all.


And I'd be a lot less frustrated if the work to get these other tools
not to need dscs and been done *before* the workflow that everyone was
using at the time was broken by the dpkg maintainer.

Re: Seeking consensus for some changes in adduser

[Sam Hartman]

> "Marc" == Marc Haber  writes:

>> But I'd ask you to look into the history of usergroups in Debian
>> as part of your decision process.

Marc> Where would I read up on that? I am not deeply enough in those
Marc> political things to be able to judge whether a discussion from
Marc> 15 years ago is still valid today.

No clue either.
Let me try asking something more reasonable.
If you end up tightening down world readableness, let me know so I can
reject the umask patch, because I suspect if your decision to tighten
down being world readable sticks, the 15 year old usergroups decision
would need to be revalidated by someone who cared.

Bug#1007227: ITP: apertium-regtest -- Regression test suite for Apertium languages and pairs

[Kartik Mistry]

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

  Package name: apertium-regtest
  Version : 0.9.0
  Upstream Author : Daniel Swanson 
  URL : https://apertium.org/
  License : GPL-3+
  Programming Lang: Python
  Description : Regression test suite for Apertium languages and pairs

Suite to run regression tests for Apertium languages and pairs.

 Q Why is this package useful/relevant?

 A Useful for testing 100s of language pairs of Apertium Machine Translation
   service.

 Q How do you plan to maintain it?

 A Package will be maintained under debian-science project at Salsa.

Re: Q: systemd-timer vs cron

[Michael Biebl]

Am 14.03.22 um 02:29 schrieb Paul Wise:

The cron feature of sending the output via email by default isn't
possible to get easily with systemd timers or systemd-cron, unless you
modify every single timer to manually send email 


See https://lists.debian.org/debian-devel/2020/01/msg00205.html







OpenPGP_signature
Description: OpenPGP digital signature