Re: Integration with systemd

Josh Triplett writes: > Part of the problem is that the people interested in sysvinit don't tend > to care about those features and often argue that others shouldn't care > either, and the people interested in those features don't tend to care > about sysvinit. It's difficult to motivate people t

Re: Integration with systemd

On Wed, Oct 30, 2019 at 01:51:07PM -0700, Josh Triplett wrote: > > So mostly, this isn't going to be up to us. It's going to be up to > > the upstream. Eventually, for each package where upstream has chosen > > to use these technologies, our choice will be (a) to drop the package > > from Debian,

Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]

This all looks very good. Presumably the repository / Salsa project name should match the source package name? If so, that might be good to note, at least as the default. I'd love to see more information about a recommended branch structure. FWIW, I've been using branches named for each release

Re: Integration with systemd

Hello, On Wed 30 Oct 2019 at 12:16PM -07, Russ Allbery wrote: > It's not clear to me whether we need a faster policy *process* or if we > just need more hands, but I completely agree that the current policy > process is too slow. I haven't had much time to work on it for about five > years; if i

Re: Integration with systemd

Russ Allbery wrote: > One of the options that I find interesting is to enumerate a list of > features in unit files that Debian supports, and require that any > Debian init system be able to handle unit files with those features. > This standardzes an *API* for both package maintainers and upstream

Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

Hello, On Tue 29 Oct 2019 at 08:32AM +01, Tobias Frost wrote: >> For example, you would not be able to do this: >>git clone salsa:something >>cd something >>make some straightforward change >>git tag# } [1] >>git push # } >> Instead you would have to download the .origs

Re: [RFC] Proposal for new source format

Hello Helmut, On Mon 28 Oct 2019 at 09:35PM +01, Helmut Grohne wrote: > On Sun, Oct 27, 2019 at 10:11:22AM -0700, Sean Whitton wrote: >> On Sat 26 Oct 2019 at 04:24PM -07, Russ Allbery wrote: >> > Hm, that's an interesting thought. I do generally include that sort of >> > information in the docu

Re: Integration with systemd

On Wed, Oct 30, 2019 at 03:30:17PM -0400, Theodore Y. Ts'o wrote: > On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote: > > Today, people can't use systemd persistent timers in place of cron (and > > in place of anacron's "wake up periodically" approach). You have to have > > a cron job

Re: Integration with systemd

> "Russ" == Russ Allbery writes: Russ> I also completely agree with Josh's message and with your Russ> other message that we need to make a lot of decisions about Russ> what systemd features packages can assume, or what workarounds Russ> they have to have in place if they can'

Re: Opera Mail is missing on Linux

On Wed, Oct 30, 2019 at 08:56:26PM +0100, patrick.dre...@gmx.net wrote: > > Dear Woman and Man! > > Opera Mail is missing on Linux > http://ftp.opera.com/ftp/pub/opera/mail/1.0/. > How is the problem solved? https://wiki.debian.org/Opera > With kind greetings! Yeah. And if we where in the s

Opera Mail is missing on Linux

Dear Woman and Man! Opera Mail is missing on Linux http://ftp.opera.com/ftp/pub/opera/mail/1.0/. How is the problem solved? With kind greetings!

Opera Mail fehlt auf Linux

Sehr geehrte Damen und Herren! Opera Mail fehlt auf Linux http://ftp.opera.com/ftp/pub/opera/mail/1.0/. Wie wird das Problem gelöst? Mit freundlichen Grüssen!

Re: Integration with systemd

"Theodore Y. Ts'o" writes: > So mostly, this isn't going to be up to us. It's going to be up to > the upstream. Eventually, for each package where upstream has chosen > to use these technologies, our choice will be (a) to drop the package > from Debian, (b) add backwards compatibility support f

Opera 12.16 on Debian 10 is not working

Dear Woman and Man! Opera 12.16 on Debian 10 is not working. http://ftp.opera.com/ftp/pub/opera/linux/1216/ How is the problem solved? With kind greetings!

Re: Integration with systemd

On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote: > > Today, people can't use systemd persistent timers in place of cron (and > in place of anacron's "wake up periodically" approach). You have to have > a cron job as well, and there's no good mechanism to automatically > prevent a cro

Re: Integration with systemd

Simon Richter writes: > I believe this GR is less about technical than about organizational > aspects. If we want to fully adopt systemd, we need a faster policy > process, which will disenfranchise users with less-common use cases, > because there is no time to integrate their concerns (I'm also

Re: Opera 12.16 on Debian 10 is not working

On Wed, Oct 30, 2019 at 06:30:35PM +0100, Andrej Shadura wrote: > Hi, > > On Wed, 30 Oct 2019, 17:43 , wrote: > > > Dear Woman and Man! > > > > Opera 12.16 on Debian 10 is not working. > > http://ftp.opera.com/ftp/pub/opera/linux/1216/ > > How is the problem solved? > > > > Debian doesn't ship

Re: Integration with systemd

[Please CC me on replies.] Simon Richter wrote: > On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote: > > If we're going to have a GR, part of the goal should be to either > > confirm the current state that we're never moving very far past the > > capabilities of sysvinit even when most

Re: Opera 12.16 on Debian 10 is not working

Am 30.10.19 um 18:30 schrieb Andrej Shadura: Hi, On Wed, 30 Oct 2019, 17:43 , > wrote: Dear Woman and Man! Opera 12.16 on Debian 10 is not working. http://ftp.opera.com/ftp/pub/opera/linux/1216/ How is the problem solved? Debian doesn't ship Op

Opera 12.16 on Debian 10 is not working

Dear Woman and Man! Opera 12.16 on Debian 10 is not working. http://ftp.opera.com/ftp/pub/opera/linux/1216/ How is the problem solved? With kind greetings!

Opera 12.16 auf Debian 10 funktioniert nicht

Sehr geehrte Damen und Herren! Opera 12.16 auf Debian 10 funktioniert nicht. http://ftp.opera.com/ftp/pub/opera/linux/1216/ Wie wird das Problem gelöst? Mit freundlichen Grüssen!

Re: TZ=UTC wrong?

Hi! On Wed, 2019-10-30 at 13:09:33 +, Colin Watson wrote: > First, is this a distinction with a meaningful difference worth spending > the time on changing it? Depends, I guess. See below. > Second, it is not correct to say that the format requires an offset. > Referring to timezone(3), the

Re: MBF: don't build against libatlas3-base if possible

On 2019-10-30 21:48, Mo Zhou wrote: We can add two lintian WARNINGs: W: linkage-against-specific-blas-lapack-implementation triggered when detected any specific BLAS/LAPACK implementation in shlibs:Depends . The package should link against the standard blas/lapack:

Re: Integration with systemd

Hi, On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote: > If we're going to have a GR, part of the goal should be to either > confirm the current state that we're never moving very far past the > capabilities of sysvinit even when most people don't run it, or that > we're allowed to us

Re: MBF: don't build against libatlas3-base if possible

Hi Ian, On Wed, Oct 30, 2019 at 01:17:20PM +, Ian Jackson wrote: > Hi. I would like to congratulate you on your work so far. I am no > expert on this area but from what I read, I want to encourage you :-). :-) > I think it's important to give the MBF recipients a clear set of > instructio

Re: [RFC] Proposal for new source format

Russ Allbery writes ("Re: [RFC] Proposal for new source format"): > Ian Jackson writes: > > Of course this means that the resulting source packages are not the "3.0 > > (quilt)" patch queue source packages that many people (even some people > > who like git) say is important to them. > > > A key

Re: TZ=UTC wrong?

Hi Holger On Wed, Oct 30, 2019 at 12:42:54PM +, Holger Levsen wrote: > On Tue, Oct 29, 2019 at 09:00:15PM +0200, Niko Tyni wrote: > > On Mon, Oct 28, 2019 at 12:28:32PM +0100, Guillem Jover wrote: > > > Just noticed this change from the changelog. :) UTC is not really a > > > proper timezone s

Re: TZ=UTC wrong?

Hi Colin, On Wed, Oct 30, 2019 at 01:09:33PM +, Colin Watson wrote: [...] > Since TZ=UTC is technically correct per timezone(3), I'd stick with it > unless there's a demonstrable practical difference (perhaps > compatibility on some odd systems?) justifying the effort involved in > changing it

Re: MBF: don't build against libatlas3-base if possible

Mo Zhou writes ("MBF: don't build against libatlas3-base if possible"): > Type: performance improvement, integration > Affected: `apt rdepends libatlas3-base` > Severity: important Hi. I would like to congratulate you on your work so far. I am no expert on this area but from what I read, I want

Re: TZ=UTC wrong?

On Wed, Oct 30, 2019 at 12:42:54PM +, Holger Levsen wrote: > On Tue, Oct 29, 2019 at 09:00:15PM +0200, Niko Tyni wrote: > > On Mon, Oct 28, 2019 at 12:28:32PM +0100, Guillem Jover wrote: > > > Just noticed this change from the changelog. :) UTC is not really a > > > proper timezone specificatio

TZ=UTC wrong?

Hi, (changed to: to debian-devel, added the r-b general list as cc: and bcc:ed Niko and Guillem.) the following came up in "#791362: perl: build timezone affects LOCALTIME_{MIN,MAX}": On Tue, Oct 29, 2019 at 09:00:15PM +0200, Niko Tyni wrote: > On Mon, Oct 28, 2019 at 12:28:32PM +0100, Guillem J

Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]

Sam Hartman dixit: >depend on non-free software. Github is a common example of a web >service that uses non-free software. So is Salsa. It does not use the packaged version of GitLab, which is in a sorry state anyway, and not suitable for a stable release, but the proprietary “open core” versioi

Integration with systemd

Russ Allbery wrote: > If we're not, we should unambiguously free people from doing > additional work that they don't want to do and can't test easily I really appreciate your mail, and I think this point is entirely true. I also feel there's a key detail to add here, in that this isn't just about

Suggestion: You should delete Mozilla ESR programs

Dear Woman and Man! Suggestion: You should delete Mozilla ESR programs otherwise you have double work for programming, testing. You should leave more time for the normal version. http://ftp.mozilla.org/pub/firefox/releases/52.0.2/linux-x86_64/en-US/ With kind Greetings!

Re: BITS from the DPL For September/October 2019

Sam, thanks for the bits mail. Very interesting as usual! Just a minor nitpick... On Tue, Oct 29, 2019 at 01:16:21PM -0400, Sam Hartman wrote: > * I spent some money. No, you didn't, Debian did, as you correctly described below. You approved that spending. -- cheers, Holger (I'm not

Re: BITS from the DPL For September/October 2019

Hi, On Tue, Oct 29, 2019 at 10:38:32PM +0100, Thomas Goirand wrote: > If we have such vote again, I'll continue on this direction: I'd prefer > if we didn't have to vote. >From a Policy perspective, packages are supposed to integrate into the system by providing init scripts, and Policy has a le

Re: BITS from the DPL For September/October 2019

> "Wouter" == Wouter Verhelst writes: Wouter> Having said that, Wouter> Sam: I notice that you've not sent a draft of your GR Wouter> proposal to the -vote mailing list yet. It has been my Wouter> experience over the years that that is not generally a good Wouter> idea.

Bug#943817: ITP: ripser -- Fast computation of persistent homology of Vietoris-Rips complexes

Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: ripser Version : 1.1 Upstream Author : Ulrich Bauer * URL : http://ripser.org * License : MIT Programming Lang: C++ Description : Fast computation of persistent homology of flag comp